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Abstract 



Session types allow communication protocols to be specified type-theoretically so that 
protocol implementations can be verified by static type checking. We extend previous work on 
session types for distributed object-oriented languages in three ways. (1) We attach a session 
type to a class definition, to specify the possible sequences of method calls. (2) We allow 
a session type (protocol) implementation to be modularized, i.e. partitioned into separately- 
callable methods. (3) We treat session-typed communication channels as objects, integrating 
their session types with the session types of classes. The result is an elegant unification of 
communication channels and their session types, distributed object-oriented programming, 
and a form of typestate supporting non-uniform objects, i.e. objects that dynamically change 
the set of available methods. We define syntax, operational semantics, a sound type system, 
and a sound and complete type checking algorithm for a small distributed class-based object- 
oriented language with structural subtyping. Static typing guarantees that both sequences of 
messages on channels, and sequences of method calls on objects, conform to type-theoretic 
specifications, thus ensuring type-safety. The language includes expected features of session 
types, such as delegation, and expected features of object-oriented programming, such as 
encapsulation of local state. The main ideas presented herein have been implemented as a 
prototype, extending Java 1.4. 

1 Introduction 

Session types [BUI [57] allow communication protocols to be specified type-theoretically, so that 
protocol implementations can be verified by static type checking. The underlying assumption is 
that we have a concurrent or distributed system with bi-directional point-to-point communication 
channels. A session type describes the protocol that should be followed on a particular channel; 
that is to say, it defines the permitted sequences, types and directions of messages. For example, 
the session type S — ! [Int] . ? [Bool] . end specifies that an integer must be sent and then a boolean 
must be received, and there is no further communication. More generally, branching and repetition 
can also be specified. A session type can be regarded as a finite-state automaton whose transitions 
are annotated with types and directions, and whose language defines the protocol. 

Session types were originally formulated for languages closely based on process calculus. Since 
then, the idea has been applied to functional languages |32lH9"l l62 54 33 , component-based object 
systems [61 , object-oriented languages [[25]; |24l 1221 123"] : [39, 13J], operating system services [26J 
and more general service-oriented systems [2]. Session types have also been generalized from 
two-party to multi-party systems [8 , 36 , although in the present paper we will only consider the 
two-party case. 

We are interested in combining session- typed channels and object-oriented programming. The 
references above can be divided into two groups. The approach of Dezani-Ciancaglini et al. is for 
a class to define sessions instead of methods. Invoking a session on an object creates a channel 
which is used for communication between two blocks of code: the body of the session, and a 
co-body defined by the invoker of the session. A session is therefore a generalization of a method, 
in which there can be an extended dialogue between caller and callee instead of a single exchange 
of parameters and result. The structure of this dialogue is defined by a session type. 



The SJ (Session Java) language developed by Hu is a less radical extension of the object- 
oriented paradigm. Channels, described by session types, are essentially the same as those in 
the original work based on process calculus. Program code is located in methods, as usual, and 
can create channels, communicate on them, and pass them as messages. SJ has a well-developed 
implementation and has been applied to a range of situations, and more recently has been extended 
to support event-driven programming. However, SJ has one notable restriction: a channel cannot 
be stored in a field. This means that a channel, once created, must be either completely used, or 
else delegated, within the same method. It is not possible for a session to be split into methods 
that can be called separately. 

In previous work [30] we proposed a new approach to combining session-typed communication 
channels and distributed object-oriented programming. Our approach extends earlier work and 
allows increased programming flexibility. We adopted the principle that it should be possible to 
store a channel in a field of an object and allow the object's methods to use the field like any other; 
we then followed the consequences of this idea. For example, consider a field containing a channel 
of type S above, and suppose that method m sends the integer and method n receives the boolean. 
Because the session type of the channel requires the send to occur first, it follows that m must 
be called before n. We therefore need to work with non-uniform objects, in which the availability 
of methods depends on the state of the object: method n is not available until after method m 
has been called. In order to develop a static type system for object-oriented programming with 
session-typed channels, we use a form of typestate |59| that we have previously presented under 
the name of dynamic interfaces |63| . In this type system, the availability of a class's methods 
(i.e., the possible sequences of method calls) is specified in a style that itself resembles a form of 
session type, giving a pleasing commonality of notation at both the channel and class levels. 

The result of this combination of ideas is a language that allows a very natural integration 
of programming with session-based channels and with non-uniform objects. In particular, the 
implementation of a session can be modularized by dividing it into separate methods that can be 
called in turn. This is not possible in SJ [39], the most closely related approach to combining 
sessions and objects. We believe that we have achieved a smooth and elegant combination of three 
important high-level abstractions: the object-oriented abstraction for structuring computation 
and data, the typestate abstraction for structuring state-dependent method availability, and the 
session abstraction for structuring communication. 

In the present paper we formalize a core distributed class-based object-oriented language with 
a static type system that combines session-typed channels and a form of typestate. The formal 
language differs from that introduced in our previous work [5U] by using structural rather than 
nominal types. This allows several simplifications of the type system. We have also simplified the 
semantics, and revised and extended the presentation. We prove that static typing guarantees two 
runtime safety properties: first, that the sequence of method calls on every non-uniform object 
follows the specification of its class's session type; second, as a consequence (because channel 
operations are implemented as method calls), that the sequence of messages on every channel 
follows the specification of its session type. This paper includes full statements and proofs of type 
safety, in contrast to the abbreviated presentation in our conference paper. We also formalize a 
type checking algorithm and prove its correctness, again with a revised and expanded presentation 
in comparison with the conference paper. 

There is a substantial literature of related work, which we discuss in detail in Section [9] Very 
briefly, the contributions of our paper are the following. 

• In contrast to other work on session types for object-oriented languages, we do not require 
a channel to be created and completely used (or delegated) within a single method. Several 
methods can operate on the same channel, thus allowing effective encapsulation of channels 
in objects, while retaining the usual object-oriented development practice. This is made 
possible by our integration of channels and non-uniform objects. This contribution was the 
main motivation for our work. 

• In contrast to other typestate systems, we use a global specification of method availability, 
inspired by session types, as part of a class definition. This replaces pre- and post-condition 
annotations on method definitions, except in the particular case of recursive methods. 
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// Style 1: method signatures with their definitions 1 

classFile{ 2 

session I n i t 3 

where Init = {open: (OK: Open, ERROR: I n i t > } 4 

Open ={hasNext: (TRUE: Read, FALSE: Close), close: Init} 5 

Read = {read: Open, close: Init} 6 

Close = {close: Init} 7 

{OK, ERROR} open(String filename) {...} 8 

{TRUE, FALSE} hasl\lext() {...} 9 

String read() {...} 10 

Null close() {...} 11 

} 12 

13 

// Style 2: method signatures in the session type 14 

classFile{ 15 

session Init 16 

where Init = { {OK, ERROR} open ( S t r i n g ) : (OK: Open, ERROR: Init)} 17 

Open ={ {TRUE, FALSE} hasNextQ: (TRUE: Read, FALSE: Close), 18 

Null closefj: Init} 19 

Read = {String read(): Open, Null close(): Init} 20 

Close = {Null closefj: Init} 21 

open ( f i I e n a m e ) {■■■} 22 

hasNext() {...} 23 

read() {...} 24 

closefj {...} 25 

} 26 



Figure 1: A class describing a file in some API, defined in two styles 



• When an object's typestate depends on the result (in an enumerated type) of a method call, 
meaning that the result must be case-analyzed before using the object further, we do not 
force the case-analysis to be done immediately by using a combined "switch-call" primitive. 
Instead, the method result can be stored in a field and the case-analysis can happen at any 
subsequent point. Although this feature significantly increases the complexity of the formal 
system and could be omitted for simplicity, it supports a natural programming style and 
gives more options to future programming language designers. 

• Our structural definition of subtyping provides a flexible treatment of relationships between 
typestates, without requiring a large inheritance hierarchy to be defined. 

The remainder of the paper is structured as follows. In Section [2] we illustrate the concept of 
dynamic interfaces by means of a sequential example. In Section [3] we formalize a core sequential 
language and in Section [4] we describe some extensions. In Section [5] we extend the sequential 
example to a distributed setting and in Section [6] we extend the formal language to a core dis- 
tributed language. In Section [7] we state and prove the key properties of the type system. In 
Section [8] we present a type checking algorithm and prove its soundness and completeness, and 
describe a prototype implementation of a programming language based on the ideas of the paper. 
Section [9] contains a more extensive discussion of related work; Section 10 outlines future work 
and concludes. 



2 A Sequential Example 

A file is a natural example of an object for which the availability of its operations depends on its 
state. The file must first be opened, then it can be read repeatedly, and finally it must be closed. 
Before reading from the file, a test must be carried out in order to determine whether or not any 
data is present. The file can be closed at any time. 

There is a variety of terminology for objects of this kind. [57 refer to them as non-uniform. 
We have previously used the term dynamic interface [63 j to indicate that the interface, i.e. the set 
of available operations, changes with time. The term typestate [59] is also well established. 

Figure [l] defines the class File , which we imagine to be part of an API for using a file system. 
The definition does not include method bodies, as these would typically be implemented natively 
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Figure 2: Diagrammatic representation of the session type of class File in Figure [T] 

by the file system. What it does contain is method signatures and, crucially a session type 
definition which specifies the availability of methods. We will refer to a skeleton class definition of 
this kind as an interface, using the term informally to mean that method definitions are omitted. 

The figure shows the same definition written in two styles. Style 1 writes method signatures 
as part of the method definitions, as is normal in many programming languages, and writes only 
method names in the session type. Style 2 writes the method signatures in the session type and 
not as part of the method definitions. Style 2 is closer to the formal language that we will define 
in Section [3j while Style 1 is sometimes less verbose. The detailed explanation of this example, 
below, refers to Style 1. 

Line 3 declares the initial session type Init for the class. This and other session types are 
defined on lines 4-7. We will explain them in detail; they are abstract states of objects, indicating 
which methods are available in a given state and which is the state after calling a method. In 
a session type, the constructor {...} , which we call branch, indicates that certain methods are 
available. In this example, Init declares the availability of one method (open), states Open and 
Read allow for two methods each, and state Close for a single method (close). For technical 
convenience, the presence of data is tested by calling the method hasNext, in the style of a Java 
iterator, rather than by calling an endOfFile method. If desired, method hasNext could also be 
included in state Read. 

The constructor ( ... ), which we call variant, indicates that a method returns a value from an 
enumeration, and that the subsequent state (session type) depends on the result. For example, 
from state Init the only available method is open, and it returns a value from an enumeration 
comprising the constants (or labels) OK and ERROR. If the result is OK then the next state is 
Open; if the result is ERROR then the state remains Init . It is also possible for a session type to 
be the empty set of methods, meaning that no methods are available; this feature is not used in 
the present example, but would indicate the end of an object's useful life. 

The session type can be regarded as a finite state automaton whose transitions correspond to 
method calls and results. This is illustrated in Figure [2j 

Lines 8-11 define the signatures of four methods. We have already explained that their defini- 
tions are omitted; however, we will soon see an example of a full class definition including method 
definitions. 

Our language does not include constructor methods as a special category, but the method open 
must be called first and can therefore be regarded as doing initialisation that might be included in 
a constructor. Notice that open has the filename as a parameter. Unlike a typical file system API, 
creating an object of class File does not associate it with a particular file; instead this happens 
when open is called. 
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class FileReader { 

session {init: {read: Final}} 
where Final = {toString: Final} 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 



file; text ; 



Null init () { 

file = new File ( ) ; 

text = ""; // Evaluates to null 



} 



Null read(String filename) { 

switch (file.open(filename)) { 



case ERROR: 



null ; 



case OK: 



while ( f . hasNext ()) 



text = text + file, read (); 



file, close (); // Returns null 

} 



} 



String toString() { text; } 



} 



Figure 3: A client that reads from a File 



The reader might expect a declaration void close () rather than Null close (); for simplicity, we 
do not address procedures in this paper, instead working with the type Null inhabited by a single 
value, null. Methods open and hasNext return a constant from an enumeration: OK or ERROR for 
method open, and TRUE or FALSE for method hasNext. Enumerations are simply sets of labels, 
and do not need to be declared with names. 

Figure [3] defines (using Style 1) the class FileReader, which uses an object of class File. 
FileReader has a session type of its own, defined on lines 2-3. It specifies that methods must 
be called in the sequence init , read, toString, toString, .... Line 5 defines the fields of FileReader. 
The formal language does not require a type declaration for fields, since fields always start with 
type Null, and are initialised to value null. Lines 7-10 define the method init , which has initial- 
isation behaviour typical of a constructor. Lines 12-19 illustrate the switch construct. In this 
particular case the switch is on the result of a method call. One of the distinctive features of 
our language is that it is possible, instead, to store the result of the method call in a field and 
later switch on the field; we will explain this in detail later. This contrasts with, for example, 
Sing# [26], in which the call/switch idiom is the only possibility. The while loop (lines 16-17) is 
similar in the sense that the result of file .hasl\lext() must be tested in order to find out whether 
the loop can continue, calling file .read(), or must terminate. Line 21 defines the method toString 
which simply accesses a field. 

Clearly, correctness of this code requires that the sequence of method calls on field file within 
class FileReader matches the available methods in the session type of class File , and that the 
appropriate switch or while loops are performed when prescribed by session types of the form 
( ... ) in class File. Our static type system, defined in Section [3] enables this consistency to be 
checked at compile-time. In order to check statically that an object with a dynamic interface such 
as file is used correctly, our type system treats the reference linearly so that aliases to it cannot 
be created. This restriction is not a problem for a simple example such as this one, but there is a 
considerable literature devoted to more flexible approaches to unique ownership. We discuss this 
issue further in Sections [9] and [TOj 

In order to support separate compilation we require only the interface of a class, including 
the session type and the signature of each method. The exact information required by our type 
system is in Figure |4j here it is very convenient to use Style 2, with the method signatures in 
the session types, and drop the method definitions completely Our formal language uses session 
types of this form, meaning that an interface is simply a session type. For example, in order to 
typecheck classes that are clients of FileReader, we only need its interface, as defined in Figure [4j 
Similarly, to typecheck class FileReader, which is a client of File , it suffices to use the interface for 
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classFile{ 1 

session I n i t 2 

where Init = {{OK, ERROR} open(String f): (OK: Open, ERROR: {})} 3 

Open = {{TRUE, FALSE} hasNext(): (TRUE: Read, FALSE: Close), 4 

Null closeQ: {}} 5 

Read = {String read(): Open, Null close(): {}} 6 

Close = {Null close (): {}} 7 

} 8 

9 

class FileReader { 10 

session {Null init ( ) : {Null read(String filename): Final}} 11 

where Final = {String toString(): Final} 12 

} 13 

14 

class FileReadToEnd { 15 

session Init 16 

where Init = {{OK, ERROR} open(String f): (OK: Open, ERROR: {})} 17 

Open = {{TRUE, FALSE} hasNext(): (TRUE: Read, FALSE: Close)} 18 

Read = {String read(): Open} 19 

Close = {Null closeQ: {}} 20 

} 21 



Figure 4: Interfaces for classes File . FileReader and FileReadToEnd 



class File in the same figure, thus effectively supporting typing clients of classes containing native 
methods. 

Figure [5] also defines the interface for a class FileReadToEnd. This class has the same method 
definitions as File . but the close method is not available until all of the data has been read. 



According to the subtyping relation defined in Section 3.3 state Init of File is a subtype of 



state Init of FileReadToEnd, which we express as File. Init <: FileReadToEnd. Init. Subtyping 
guarantees safe substitution: an object of type File . Init can be used whenever an object of type 
FileReadToEnd. Init is expected, by forgetting that close is available in more states. As it happens, 
FileReader reads all of the data from its File object and could use a FileReadToEnd instead. 



3 A Core Sequential Language 

We now present the formal syntax, operational semantics, and type system of a core sequential 
language. As usual, the formal language makes a number of simplifications with respect to the 
more practical syntax used in the examples in Section [2j 

• All objects are non-uniform, with session types, and are treated strictly linearly by the type 
system. A practical language would also need standard objects, treated non-linearly. Adding 
them to the type system, orthogonally to linear objects, is straightforward but complicates 
and obscures the typing rules. 

• Every method has exactly one parameter. This does not affect expressivity, as multiple pa- 
rameters can be passed within an object, and a dummy parameter can be added if necessary: 
we consider a method call of the form f.m() as an abbreviation for /.m(null). It is easy to 
generalize the definitions to allow arbitrary numbers of parameters, but again at the expense 
of complicating the typing rules. 

• Field access and assignment are defined in terms of a swap operation / e which puts 
the value of e into the field / and evaluates to the former content of /. This operation is 
formally convenient because, due to strict linearity, extracting the value of a field also requires 
updating its value to null. The normal assignment operation / = e is an abbreviation for 
/ f-> e; null (where the sequence operator explicitly discards the former content of /) and 
field access as the standalone expression / is an abbreviation for / <-> null. 

• The formal system only uses Style 2, with method signatures appearing in session types and 
only there. This simplifies the treatment of subtyping and, when we consider a distributed 
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Class dec 


D : 


:= class C {S;f,M} 




Label sets 


E : 


:= 0,---,0 




Types 


T : 


:= Null | S | E | linkthis 




Method dec 


M : 


:= m(x) {e} 




Values 


v : 


:= null | I 




Paths 


r : 


:= this 




Expressions 


e : 


:= v | f.m(e) \ x | e;e | 


switch (e) {I : e ; } ;eB 


Class session types 


S : 


:= {T/ m i (T i ) : Si} ieI | <* 





Figure 5: Top level syntax 



Types 


T 


:= ... | link / | C[F] 


Field types 


F 


■= {Tifihel I (i:Pi>j£B 


Values 


V 


:= ... | o 


Paths 


r 


■= o | r.f 


Expressions 


e 


:= ... | return e 


Object records 


R 


:= = « 4 } ie /] 


Heaps 


h 


:= £ | A,{o = R} 


States 


s 


:= (/i * r; e) 


Contexts 


£ 


:= [_] | £;e | switch (£) {/ 



The productions for types, values and expressions extend those in Figure [5] Session types may never contain types 
of the form link /, even in the extended syntax. 



Figure 6: Extended syntax, used only in the type system and semantics 



language, of channels. It also supports a form of overloading, allowing a method to have 
different signatures at different points in the same session type. 

• When a method is followed by a variant session type, the return type of the method is the 
special type linkthis rather than the set of labels from the variant. 

Our prototype implementation, described briefly at the end of Section [Hj does not make these 
simplifications and its syntax is closer to that of Section [2] 

3.1 Syntax 

We separate the syntax into the top-level language (Figure [5| and the extensions required by the 
type system and operational semantics (Figure[6|. Identifiers C, to, / and I are taken from disjoint 
countable sets representing names of classes, methods, fields and labels respectively. The vector 
arrow indicates a sequence of zero or more elements of the syntactic class it is above. Similarly, 
constructs indexed by a set denote a finite sequence. We use E to specifically denote finite sets of 
labels I, whereas / is any finite indexing set. 

Field names always refer to fields of the current object; there is no qualified field specification 
o.f. In other words, all fields are private. Method call is only available on a field, not an arbitrary 
expression. This is because calling a method changes the session type of the object on which the 
method is called, and in order for the type system to record this change, the object must be in a 
specified location (field). 

A program consists of a sequence of class declarations D. In the core language, types in a 
top-level program only occur in the session part of a class declaration: no type is declared for 
fields because they can vary at run-time and are always initially null, and method declarations are 
also typeless, as explained earlier. 

A session type S corresponds to a view of an object from outside. It shows which methods can 
be called, and their signatures, but the fields are not visible. We refer to {T/ m,*(Tj) : Si}i^i as a 
branch type and to (I : Si)i^e as a variant type. Session type end abbreviates the empty branch 
type {}. The core language does not include named session types, or the session and where clauses 
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from the examples; we just work with recursive session type expressions of the form fiX.S, which 
are required to be contractive, i.e. containing no subexpression of the form )aX\.- ■ ■ fj,X n .Xi. The 
/i operator is a binder, giving rise, in the standard way, to notions of bound and free variables 
and alpha-equivalence. A type is closed if it includes no free variables. We denote by T{ u /x} the 
capture-avoiding substitution of U for X in T. 

Value types which can occur either as parameter or return type for a method are: Null which 
has the single value null, a session type S which is the type of an object, or an enumerated type 
E which is an arbitrary finite set of labels I. Additionally, the specific return type linkthis is used 
for method occurrences after which the resulting session type is a variant, and means that the 
method result will be the tag of the variant (hence linked to this variantly-typed object). The 
set of possible labels appears in the variant construct of the session type, so it is not necessary 
to specify it in the return type of the method. However, in the example code, the set of labels is 
written instead of linkthis, so that the method signature shows the return type in the usual way. 

The type system, which we will describe later, enforces the following restrictions on session 
types: the immediate components of a variant type are always branch types, and the session type 
in a class declaration is always a branch. This is because a variant type is used only to represent 
the effect of method calls and the dependency between a method result and the subsequent session 
type, so it only makes sense immediately within a branch type. 

Figure [6] defines additional syntax that is needed for the formal system but is not used in top- 
level programs. This includes some expressions that arise from the operational semantics, some 
extra forms of type that are used in the proof of type preservation in order to type expressions 
arising from the operational semantics, and syntax for the heap. 

The first addition is the type link /. When a field / is given a variant type, the corresponding 
tag, which in our language is a separate value, has type link /. It is not possible for these tags to 
be returned from a method or passed as parameters, hence they cannot appear in the declarations 
and are not part of the syntax of programs. There is also an alternative form of object type, C[-F], 
which has a field typing instead of a session type. It represents the view of an object from within 
its own class and is used when typing method definitions. A field typing F can either be a record 
type associating one type to each field of the object or a variant field typing (I : -F/)/gE, indexed 
by the values of an enumerated set E, similar to a variant session type. 

The other additions are used to define the operational semantics. A heap h maps object 
identifiers o, taken from yet another countable set of names, to object records R. We write 
dom(h) for the set of object identifiers in h. The identifiers are values, which may occur in 
expressions. The operation h, {o — R} represents adding a record for identifier o to the heap h 
and we consider it to be associative and commutative, that is, h is essentially an unordered set 
of bindings. It is only defined if o ^ dom(h). Paths r represent locations in the heap. A path 
consists of a top-level object identifier followed by an arbitrary number of field specifications. We 
use the following notation to interpret paths relative to a given heap. 

Definition 3.1 (Heap locations) 

• If R = C[{fi = Vi}i£i], we define R.fi — Wj (for all i) and R. class = C . For any value v and 
any j £ I , we also define R{fj i— > v} = C[{/j = t^ligj] where v[ = u,; for i ^ j and v'j = v. 

• If h = (h',{o = R}), we define h(o) = R, and for any field f of R, h{o. f i— > v} = (hf , {o = 

/.'!/• "•!!••• 

• If r = r'.f and h{r').f = o, then we also define h{r) — h(o) and h{r.f i— > v} = h{o.f i— > v}. 

• In any other case, these operations are not defined. Note in particular that h(r) is not defined 
if r is a path that exists in h but does not point to an object identifier. 

There is a new form of expression, return e, which is used to represent an ongoing method call. 

Finally, a state consists of a heap and an expression, and the operational semantics will be 
defined as a reduction relation on states; £ are evaluation contexts in the style of Wright and 
Felleisen [64 , used in the definition of reduction. 

The semantic and typing rules we will present next are implicitly parameterized by the set of 
declarations D which constitute the program. It is assumed that the whole set is available at any 
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(R-Return) (h*r.f; return v) — >(h*r; v) (R-Call) 
(R-Switch) - 
(R-Swap) 



(R-Seq) (h*r; v;e) — > (h * r\ e) 

m(x) {e} £ h(r.f). class 



(h*r\ f.m(v)) — > (h*r.f; return e{ v / x }) 

lo £ E 

(h * r; switch (l ) {I : e;} ieB ) — > (h * r; e lo ) 

h(r).f = v 



(h* r; / «-> u') — > (h{r.f h> d'} * r; ij) 

ogdom(h) C.fields = / (ft * r; e) — ><h'*r';e') 

(R-New) - — == r (R-Context) 



(ft * r; new C()) — > (h, {o = C[f = nuli]} * r; o) (& * r i £[ e D — ► * r ; £[ e 'D 

Figure 7: Reduction rules for states 

poinlQand that any class is declared only once. We do not require the sets of method or field names 
to be disjoint from one class to another. We will use the following notation: if class C {S; /; M} is 
one of the declarations, C.session means S and C.fields means /, and if m(x) {e} € M then Cm 
is e. 

3.2 Operational Semantics 

Figure [7] defines an operational semantics on states (h * r; e) consisting of a heap, a path in the 
heap indicating the current object, and an expression. All rules have the implicit premise that 
the expressions appearing in them must be defined. For example, / O v only reduces if h(r) is 
an object record containing a field named /. An example of reduction, together with typing, is 
presented in Figure p~2] and discussed at the end of the present section. 

The current object path r is used to resolve field references appearing in the expression e. 
Except in the case of R-Context, e is always a part of a partially reduced method body, and r 
shows the location in the heap of the object on which the method was called. The current object 
path behaves like a call stack: as shown in R-Call, when a method call on a field / (relative to 
the current object located at r) is entered, the object in r.f becomes the current object; this is 
indicated by changing the path to r.f. Additionally, the method body, with the actual parameter 
substituted for the formal parameter, is wrapped in a return expression and replaces the method 
call. When the body has reduced to a value, this value is unwrapped by R-Return which also 
pops the field specification / from the path, recovering the previous current object r. R-New 
creates a new object in the heap, with null fields. R-Swap updates the value of a field and reduces 
to its former value. 

R-SwiTCH is standard. R-Seq discards the result of the first part of a sequential composition. 
R-Context is the usual rule for reduction in contexts. 

To complete the definition of the semantics we need to define the initial state. The idea is to 
designate a particular method m of a particular class C as the main method, which is called in 
order to begin execution. The most convenient way to express this is to have an initial heap that 
contains an object of class C, which is also chosen as the current object, and an initial expression 
e which is the body of m. The initial state is therefore 

(top = C[C.fields = null] * top; e). 

Strictly speaking, method m must have a parameter x; we take x to be of type Null and assume 
that it does not occur in e. 

Alternatively, if we want the initial expression to be a call of m, then remembering that a 
method call must be on a field we have to introduce another object, of a dummy class D, with a 
field containing the object of class C on which m is called: 

(top = D[f = c], c = C[C.fields = null] * top; /.m(null)). 



1 This is assumed for simplicity, but it is easy to check that when typing a toplevel program, the body of 
a method or class is never used outside that particular method or class — hence respecting encapsulation and 
allowing separate checking and compilation. The only information needed is a session declaration for every class 
being instantiated. Conversely, the semantic rules do not need any type information and, in particular, completely 
ignore session declarations. 
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E C E' WleE,Fi<:F[ 
(I ■ Fi)ieE <■■ (I ■ F[) leE , 



Figure 8: Subtyping rules for fields 

3.3 Subtyping 

Two kinds of types in the top-level core language are subject to subtyping: enumerated types and 
session types. The internal language also has field typings; subtyping on them is derived from 
subtyping on top-level types by the rules in Figure [8] 

Subtyping for enumerated types is simply set inclusion: E <: E' if and only if E C E' . We refer 
to subtyping for session types as the sub-session relation. Because session types can be recursive, 
the sub-session relation is defined coinductively, by defining necessary conditions it must satisfy 
and taking the largest relation satisfying them. The definition involves checking compatibility 
between different method signatures, which itself is dependent on the whole subtyping relation. 
We proceed as follows: given a candidate sub-session relation 1Z, we define an "^-compatibility 
relation between types and between method signatures which uses TZ as a sub-session relation. We 
then use ^-compatibility in the structural conditions that TZ must satisfy in order to effectively 
be a sub-session relation. 

Let S denote the set of contractive, closed session types. We deal with recursive types using 
the following unfold operator: 

Definition 3.2 (Unfolding) The operator unfold is defined inductively on S by unfold(/iJf .5) = 
unfo\d(S{^ x s y x }) and unfold(S) = S if S is not of the form fiX.S. Since the types in S are 
contractive, this definition is well-founded. 

We now define the two compatibility relations we need. 

Definition 3.3 ("^-Compatibility (Types)) LetTZ be a binary relation onS. We say that type 
T is TZ- compatible with type T' if one of the following conditions is true. 

1. T = T 

2. T and T' are enumerated types and T C T" 

3. T,T' eS and (T, T') e TZ. 

Definition 3.4 (TvL-Compatibility (Signatures)) Let TZ be a binary relation on S. Let a = 
U m(T) : S and a' = V m(T') : S' be components of branch types, both for the same method 
name m, i.e. method signatures with subsequent session types. We say that a is TZ-compatible with 
a' if T' is TZ-compatible with T and either: 

1. U is TZ-compatible with U' and (S,S') £ TZ, or 

2. U is an enumerated type E, U' = linkthis and ((I : S)i£E,S l ) G TZ. 

The compatibility relation on method signatures is, as expected, covariant in the return type 
and the subsequent session type and contravariant in the parameter type, but with one addition: 
if a method has an enumerated return type E and subsequent session type S, then it can always 
be used as if it had a return type of linkthis and were followed by the uniform variant session type 
(I : S)i<=e- Indeed, both signatures mean that the method can return any label in E and will 
always leave the object in state S. However, subtyping is in one direction only because usage of 
labels with a link type is more restricted; for example, they cannot be discarded. 

We can now state the necessary conditions for a sub-session relation. 

Definition 3.5 (Sub-session) Let TZ be a binary relation on S. We say that TZ is a sub-session 
relation if (S, S") € TZ implies: 

1. //unfold (5) = {U t rriiiTi) : S % } zeI then unfold (S") is of the form {C/j m^Tj) : Sfi^j with 
J C /, and for all j G J , Uj nij{Tj) : Sj is TZ-compatible with C/j mj(Tj) : Sj. 



Vi 6 I,Ti <: T! 

(S-Record) (S- Variant) 

{Ti fi}iei <■ { T i fi}iei 

(S-Field) L^iJl 

C\F] <: C\F'\ 
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2. If unfold(5) = (I : Si)i eE then unfold(S") is of the form (I : S[)i & e' with E C E' and for all 

I eE, (Si, si) eK. 

For the sake of simplicity we will now, when we refer to this definition later on, make the unfolding 
step implicit by assuming, without loss of generality, that neither S nor S' is of the form fiX.S". 

Lemma 3.6 The union of several sub-session relations is a sub-session relation. 

Proof. Let 1Z — [J ieI IZi, where the TZi are sub-session relations. Let (S,S') £ 7Z. Then there is j 
in / such that (S, S') £ TZj. This implies that (S, S') satisfies the conditions in Definition 3.5 with 



respect to TZj. Just notice that, because TZj C TZ, the conditions are satisfied with respect to TZ 
as well — in particular, TZ j -compatibility implies 7^-compatibility. Indeed, the conditions for TZ 
only differ from those for TZj by requiring particular pairs of session types to be in 7Z rather than 
in TZj, so they are looser. 

We now define the subtyping relation <: on session types to be the largest sub-session relation, 
i.e. the union of all sub-session relations. The subtyping relation on general top-level types is just 
< ^compatibility. 

Subtyping on session types means that either both are branches or both are variants. In the 
former case, the supertype must allow fewer methods and their signatures must be compatible; 
in the latter case, the supertype must allow more labels and the common cases must be in the 
subtyping relation. Like the definition of subtyping for channel session types |31j . the type that 
allows a choice to be made (the branch type here, the © type in [3T]) has contravariant subtyping 
in the set of choices. 

The following lemma shows that the necessary conditions of Definition |3.5| are also sufficient 
in the case of <:. 

Lemma 3.7 1. Let S = {U, m^T*) : Si} ieI and S' = {U' 3 m^Tj) : S'^^j with J CI. If for 
all j £ J, Uj m,j(Tj) : Sj is <:-compatible with f/j rrij(Tj) : S'j, then S <: S' . 

2. Let S = (I : Si)i<=e arid S' = (I : S[)iqe' with E C E' . If for all I in E we have Si <: S[, 
then S <: S'. 

Proof. The relation <: UKS 1 , S')} is a sub-session relation. 

Finally, we prove that this subtyping relation provides a preorder on types. 

Proposition 3.8 The subtyping relation is reflexive and transitive. 

Proof. First note that session types can only be related by subtyping to other session types; the 
same applies to enumerated types and, in the internal system, field typings. Since the relation 
for enumerated types is just set inclusion, we already know the result for it. We now prove the 
properties for session types; the fact that they hold for field typings is then a straightforward 
consequence. 

For reflexivity, just notice that the diagonal relation {(S 1 , S) \ S £ S} is a sub-session relation, 
hence included in <:. 

For transitivity, what we need to prove is that the relation 7Z = {(S, S') | 35", S <: S" A S" <: 
S'} is a sub-session relation. Let (S, S') £ 7Z and let S" be as given by the definition of 7?.. 
In case (1) where we have S — {Ui nii(Ti) : S^}.^/, we know that: 

• 5"' = {U'j' m {T'j) : with J C J, and for all j £ J, a 3 = U, m % {T % ) : Sj is <:- 
compatible with a'J = U'j' m^Tj') : S'J. 

• Therefore, S' is of the form {U' k m k (T' k ) : S' k } k eK with K C J, and for all k £ K, <r' k ' is 
Ocompatible with a' k =U' k m,k(T k ) : S' k . 

Straightforwardly K C /. For every k in K, we have to prove that a k is ^-compatible with a' k . We 
deduce it from the two < ^compatibilities we know by looking into the definition of compatibility 
point by point: 

• We have T' k <: T k and T' k <: T' k . Either these types are all session types, and then 
(T k , T k ) £TZhy definition of 7Z, or none of them is and we have T' k <:T k by transitivity of 
subtyping on base types. In both cases, TL is ^-compatible with T k . 



11 



• We also have either: 



- Uk <■ U k , U k <: U' k , Sk <: S k and S' k ' <: S' k . In this case, the former two conditions 
imply, similarly to the above, that Uk is 72.-compatible with U' k . The latter two imply 

(s k ,s' k )en. 

- Or U k is an enumerated type E, U k = U' k = linkthis, (I : S k )ieE <■ S k and S k <: S' k . 
Then we have ((I : Sk)i^E, S' k ) £ TZ, which is all we need. 

- Or, finally, Uk is an enumerated type E, U k is an enumerated type E" such that 
E C E", S k <: S' k ' and (I : S%}i eE " <■ S' k . Then from S k <: S' k ' and E C E" we 
deduce, using case (2) of Lemma 3.7 (I : Sk)ieE <■ (I '■ S k )i e E" ■ We thus have, again, 



((I : Sk)ieE, S' k ) £ TZ which is the required condition. 

In case (2) where we have S — (I : Si)i & e, we obtain S" — (I : S',')i^e" and S' — (I : S',)i£E', 
with E C E" C E' and for any / in E, Si <: S" and S" <: S' l} which imply by definition of TZ 
that {S h SI) is in TZ. 

Definition 3.9 (Type equivalence) We define equivalence of session types S and S' as S <: S' 

and S' <: S. This corresponds precisely to S and S' having the same infinite unfoldings (up 
to the ordering of cases in branches and variants). Henceforth types are understood up to type 
equivalence, so that, for example, in any mathematical context, types fiX.S and S{^ x yx} can 
be used interchangeably, effectively adopting the equi-recursive approach ]5S\ Chapter 21]. 



3.4 Type System 

We introduce a static type system whose purpose is to ensure that typable programs satisfy a 
number of safety properties. As usual, we make use of a type preservation theorem, which states 
that reduction of a typable expression produces another typable expression. Therefore the type 
system is formulated not only for top-level expressions but for the states (i.e. (heap, expression) 
pairs) on which the reduction relation is defined. 

An important feature of the type system is that the method definitions within a particular 
class are not checked independently, but are analyzed in the order specified by the session type of 
the class. In Figure [9] rule T-Class (last rule) uses a consistency relation between field typings 
and session types, defined in Section |3.4.2| This relation in turn uses the typing judgement for 
expressions, which is defined by the other rules in Figure [9j 

In the following sections we describe the type system in several stages. 



3.4.1 Typing expressions 

The typing judgement for expressions is T * r > e : T < V * r' . In such a judgement, T is a type 
environment that maps object identifiers and parameter names to types, and r is the path to the 
current object in T. The expression e and its type T appear in the central part of the judgement. 
The r' and r' on the right hand side show the change, if any, that e causes in the type environment 
and current object path. There are several reasons for T' to differ from T; the most important is 
that if e contains a method call on object o then the difference between T and V shows that the 
session type of o changes. Any difference between r and r' means that e contains return; in that 
case, r and r' represent the call stack during and after a method call. 

When typing an expression as part of a top-level program, the typing judgement has the 
particular form this : C[F], V * this > e : T < this : C[F'], V' * this. Here the only object reference 
in the type environment is this, symbolically representing the object in which e occurs as part of 
a method body. The rest of the environment, V, has the form x : U where U is the type of the 
parameter of the method (hence a top-level type). The initial type of this is the internal type 
C[F], where F is a field typing; the final type is C[F'], as e may change the types of the fields 
(for example, by calling methods on them). The final parameter typing V' is either the same as 
V, if the parameter has a non-linear type, or empty, if the parameter has a linear type and is 
consumed by e. The path to the current object is this on both the left hand side and the right 
hand side of the judgement; that is the only possibility, because this is the only object reference 
in the environment; also, because e is a top-level expression, it does not contain return, which is 
the only expression that can change the current object path. 
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(T-Null) r * r > null : Null < T * r (T-Label) r * r > I : {1} < T * r 

(T-New) r * r > new CQ : C.session < V * r (T-LinVar) F,x: S*rt>x: S<V*r 

T is not an object type 



(T-Var) 

V * r r> p ■ r , 

(T-Swap) 



r,x:T*r>x:T<T,x:T*r 
T*r>e:T<r'*r' V'(r'.f) = T" 7V linkthis T" is not a variant 



(T-Call) 

(T-Seq) 



r*T->/«e:T'< T'{r'./ (-> T} * r' 

r * r > e : T; < T' * r> r'(r'./) = {T, m^T/) : Sj} i6/ 

j£j T = link / if = linkthis, T = Tj otherwise 



r * r > /.mj(e) : T < r'{r'./ i-* Sj} * r' 
r * r > e : T < T' * r' r' * r' > e' : T' < T" * r' T ^ link _ or linkthis 



T * r > e; e' : T" < T" * r' 

T *r > e: E' <Y' *r' E' C E Vi e E' ,V * r' > e, : T < T" * r' 

(T-Switch) 

r* r > switch (e) {i : e ; } ieE : T < V" * r' 

r*r>e: link / < F' * r' T'(r'./) = (I : S,) Jes , 

E'CE VZ e E',r'{r'.f ^ Si} * r' > e t : T < V" * r' 

(T-SwitchLink) 

r * r > switch (e) {I : ei}i SE : T < T" * r' 

r*rt>e:B<r'*r' r'(r') = CfF'l F' is a record 

(T-VarF) — — 

r*r > e : linkthis < T'{r' C[(l : F') leB ]}*r' 

(T-Sub) (T-SubEnv) 



r*n>e:T'<r'*r' " r * r > e : T < T" * r' 

Nufi/ h C : S 

(T-Class) ^ 

h class C* {S; /; M} 

Figure 9: Typing rules for the top level language 



We define notation for interpreting paths relative to type environments, analogously to Defi- 
nition [3T] for heaps. 

Definition 3.10 (Locations in environments) 

• IfT = T',o:T then we define T(o) = T and T{o i— > T'} =T',o : T' 

• Inductively, if r = r'.f, and ifT(r') — C[F] where F is a record field typing containing f, 
then T(r) is defined as F(f) and T{r ^ T'} as T{r' h-> C[F{f ^ T'}]}. 

• In any other case, these operations are not defined. In particular, ifT{r') is defined but is a 
session type, then Y(r' .f) is not defined for any f. 

A pair r * r only makes sense if T(r) is defined and is of the form C[F\. 
We extend subtyping to a relation on type environments, as follows. 

Definition 3.11 (Environment subtyping) T <: V if for every a £ dom(T'), where a is 
either a parameter or an object identifier, we have a € dom(T) and T(a) <: T'(a). 

Essentially T <: T' if T is more precise (contains more information) than T': it contains types for 
everything in T' (and possibly more) and those types are more specific. 

3.4.2 Consistency between field typings and session types 

There are two possible forms for the type of an object. One is a session type S, which describes 
the view of the object from outside, i.e. from the perspective of code in other classes. The session 
type specifies which methods may be called, but does not reveal information about the fields. The 
other form, C[F], contains a field typing F, and describes the internal view of the object, i.e. from 
the perspective of code in its own methods. Consider a sequence of method calls in a particular 
class. There are two senses in which it may be considered correct or incorrect. (1) In the sense 
that it is allowed, or not allowed, by the session type of the class. (2) In the sense that the field 
typings before and after each method call follow each other in a connected way. In order to type 



13 



a class definition, these two senses of correctness must be consistent according to the following 
coinductive definition. 



Definition 3.12 Let C be a class and let 1Z be a relation between field typings F and session 
types S. We say that 1Z is a C -consistency relation if (F, S) G TZ implies: 

1. If S — {Ti 77ij(T/) : Si}i£i, then F is not a variant and for all i in I, there is a definition 
rrii(xi) {ei} in the declaration of class C such that we have this : C[F],Xi : T[ * this > a : 
Ti < this : C[Fi] * this with F t such that (Fi, Si) € TZ. 

2. If S = (I : Si)ieE> then F = {I : Fi)i^e' with E' C E and for all I in E' we have (Fi, Si) € TZ. 

The definition implies that a method with return type linkthis must be followed by a variant 
session type, for the following reason. Suppose that in clause (1). some Tj is linkthis. The only 
way for e, to have type linkthis is by using rule T-VarF, which implies that Fi must be a variant 
field typing. The condition (i^, Si) € TZ implies, by clause (1), that S% is a variant. 

Lemma 3.13 The union of several C-consistency relations is a C-consistency relation. 



Proof. Similar to (but simpler than) the proof of Lemma 3.6 For any class C, we define the 
relation F h C : S between field typings F and session types S to be the largest C-consistency 
relation, i.e. the union of all C-consistency relations. 

The relation F h C : S represents the fact that an object of class C with internal (private) 
field typing F can be safely viewed from outside as having type S. The second point accounts for 
correspondence between variant types. The main point is the first: if the object's fields have type 
F and its session type allows a certain method to be called, then it means that the method body is 
typable with an initial field typing of F and the declared type for the parameter. Furthermore, the 
type of the expression must match the declared return type and the final type of the fields must 
be compatible with the subsequent session type. The parameter may or may not be consumed by 
the method, but T-SubEnv at the end of Figure [9] allows discarding it silently in any case, hence 
its absence from the final environment. 

The rule T-Class, last rule in Figure [9] checks that the initial session type of a class is 
consistent with the initial Null field typing. It refers to the above definition of consistency, which 
itself refers to typing judgements built using the other rules in the figure. 



3.4.3 Typing rules for top-level expressions 

The typing rules for top-level expressions (the syntax in Figure |5| are in Figure [9] T-Null and 
T-Label type constants. A label is given a singleton enumerated type, which is the smallest type 
it can have, but subsumption can be used to increase its type. T-New types a new object, giving 
it the initial session type from the class declaration. T-LinVar and T-Var are used to access a 
method's parameter, removing it from the environment if it has an object type (which is linear). 
For simplicity, this is the only way to use a parameter. In particular, we do not allow calling 
methods directly on parameters: to call a method on a parameter, it must first be assigned to a 
field. T-Swap types the combined read-write field access operation, exchanging the types of the 
field and expression. There are two restrictions on its use. T is not allowed to be linkthis, because 
that would mean creating a variant field typing and hiding the tag instead of returning it from a 
method. This implies that T'(r') is not a variant, because the only rule that could produce one is 
T-VarF, which would also give T = linkthis; hence T'(r'.f) is defined. Also, T' is not allowed to 
be a variant, because in that case removing the contents of / would invalidate the link type that 
points to it. 

T-Call checks that field / has a session type that allows method mj to be called. The type 
of the parameter is checked as usual, and the final type environment is updated to contain the 
new session type of the object in /. If the return type of the method is linkthis, it means that the 
value returned is a label describing the state of this object; since the object is in /, it is changed 
into link /. Because the return type appears in the session type and is therefore expressed in the 
top-level syntax, it cannot already be of the form link /. 

T-Seq accounts for the effects of the first expression on the environment and checks that a 
label is not discarded, which would leave the associated variant unusable. 
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r^of r *r > e : E < V *r' T'(r'.f) = S 5 is a branch 

(T-Ref) - —^1—— (T-VarS) 



T,o:T*r> o:T <T*r T * r > e : link / < T'{r'.f h-> <« : S) !si5 } * r' 

r * r > e : T < r * r'./ V(r'.f) = C[F] F h C : S 

T J= link T' = link f if T = linkthis, T' = T otherwise 

(T-Return) = - 

r * r > return e : T' < T'{r'.f S} * r' 

Figure 10: Typing rules for expressions in the internal language 



T-SwiTCH types a switch whose expression e does not have a link type. All relevant branches 
are required to have the same type and final environment, and the whole switch expression inherits 
them. A typical example is if the branches just contain different labels: in that case they are given 
singleton types by T-Label and then T-Sub is used to give all of them the same enumerated 
type. If the type E' of the parameter expression is strictly smaller than the set E of case labels 
in the switch expression, branches corresponding to the extra cases are ignored. 

T-SwitchLink is the only rule for deconstructing variants. It types a switch, similarly to 
the previous one, but the type of e must be a link to a field / with a variant session type. The 
relevant branches are then typed with initial environments containing the different case types for 
/ according to the value of the label. As before, they must all have the same type and final 
environment, and if the switch expression defines extra branches for labels which do not appear 
in the variant type of /, they are ignored. 

T-VarF constructs a variant field typing for the current object. Here E is typically, but not 
necessarily, a singleton type, and e is typically a literal label. The field typing before applying 
the rule must be a record as nested variants are not permitted, and the rule transforms it into a 
variant with identical cases for all labels in E. It can then be extended to a variant with arbitrary 
other cases using rule T-SubEnv. This rule is used for methods leading to variant session types, 
which, as Definition |3.12| implies, must finish with a variant field typing. As a simple example, 
consider the following expression, which could end a method body in some class D: 

switch (e) {TRUE : / o new C(); OK, FALSE : / O null; ERROR} 

If S is the declared session type of class C, we have, using rules T-SWAP, T-Label and T-Seq, 
the following judgements (T is just the initial type of /): 

this : D[T /] * this t> / O new C(); OK : {OK} < this : D[S f] * this 

and 

this : D[T f] * this >/■<-> null; ERROR : {ERROR} < this : D[Null /] * this. 

Then T-VarF can be applied to both these judgements, giving both expressions the same type 
linkthis, and giving at the same time to this, in the final environment, the variant types D[(OK : 
{S /})] and D[(ERROR : {Null /})] respectively. These two types are both subtypes of the 
combined variant D[(OK : {S /}, ERROR : {Null /})] and T-SubEnv can thus be applied to both 
judgements to increase the final type of this to this common supertype. It is then possible to 
use T-SwiTCH to type the whole expression. Note that the final type of the expression is always 
linkthis: as T-VarF is the only rule for constructing variants, this is the only possible return type 
for a method leading to a variant. 

T-Sub is a standard subsumption rule, and T-SubEnv allows subsumption in the final en- 
vironment. The main use of the latter rule, as illustrated above, is to enable the branches of a 
switch to be given the same final environments. 



3.4.4 Typing rules for internal expressions, heaps and states 

The type system described so far is all we need to type check class declarations and hence programs, 
which are sequences of class declarations. In order to describe the runtime consequences of well- 
typedness, we now introduce an extended set of typing rules for expressions that occur only at 
runtime (Figure 10 1 and for program states including heaps (Figure 111. 

Runtime expressions may contain object identifiers, typed by T-Ref. In this rule, the current 
object path r must not be within o, meaning that the current object or any object containing 



15 



hh-.r r,o:C[{NuII/ i }i^ n ]*o[>/i-H-Di;---;/n-H-Dn:Null<r'*o 

(T-Hempty) h e : (T-Hadd) 

l-ft,{o = C[{/ i = « i }i <<<n ]}:r' 

(T-Hide) — (T-State) — — 

v ; hh:T,o:S V > (ft * r; e) : T < T' * r' 

Figure 11: Typing rules for states 



it cannot be used within an expression. This is part of the linear control of objects: somewhere 
there must be a reference to the object at r, in order for a method to have been called on that 
object, which is what gives rise to the evaluation of an expression whose current object path is 
r. So obtaining another reference to the object at r, within the active expression, would violate 
linearity. 

Another new rule is T-VarS, which constructs a variant session type for a field of the current 
object. At the top level, the only expression capable of constructing a variant session type is a 
method call, but once the method call has reduced into something else this rule is necessary for 
type preservation. 

The last additional rule for expressions is T-Return, which types a return expression repre- 
senting an ongoing method call. The subexpression e represents an intermediate state in a method 
of object r'.f. As such, it is typed with final current object r'.f and a final environment where 
the type of r'.f is of the form C[F], representing an inside view of the object, where the fields 
are visible. This rule then steps out of the object, hides its fields and changes its type into the 
outside view of a session type, which must be consistent with the internal type (F h C : S). The 
particular case where T is linkthis is the same as in T-Call. T is not allowed to already be of 
the form link /' since it would break encapsulation (/' would refer to a field of r'.f which is not 
known outside of the object) . 

An important point is that the only expression that changes the current object is return. 
Several rules besides T-Return can inherit in the conclusion a change of current object from a 
subexpression in a premise, but they do not add further changes. Thus the final current object 
path is always a prefix of the initial one, and the number of field specifications removed is equal 
to the number of returns contained in the expression. Also note that the second part of a sequence 
and the branches of a switch are not reduction contexts; therefore, they should not contain return 
and are not allowed by the rules to change the current object. 

As we saw in Section |3.2[ a runtime state consists of a heap, a current object path, and a 
runtime expression. Figure [TT] describes how these parts are related by typing: a typing judgement 
for the expression gives one for the state provided the current object is the same and the initial 
environment reflects the content of the heap; this last constraint is represented by the judgement 
h h : r. Such a judgement is constructed starting from the axiom T-HEmpty which types an 
empty heap and adding objects into the heap one by one with rule T-HAdd, converting their 
types into sessions using T-Hide as needed. As T-HAdd is the only rule that adds to T, we have 
the property that h h : T implies that every identifier in T also appears in h. 

T-HAdd essentially says that adding a new object with given field values to the heap affects 
the environment in the same way as an expression that starts from an empty object and puts the 
values into the fields one by one. The most important feature of this rule is that whenever a Vi 
is an object identifier, the typing derivation for the expression has to use T-Ref, which implies 
both that the initial environment contains Vi and that the final one, which represents the type of 
the extended heap, does not. This means that a type environment corresponding to a heap never 
contains entries for object identifiers that appear in fields of other objects, and it also implies that 
a heap with multiple references to the same object is not typable. The numbering of the fields in 
the rightmost premise is arbitrary, meaning it must not be interpreted as requiring the sequence 
of swaps to be done in any particular order; all possible orders are valid instances of the premise. 
This is important if the type of the object being added is to contain links and variants: suppose 
that field / contains an object o and field g a label I; it must be possible to attribute a variant 
type to / and the type link / to g, but this can only be done as a result of typing the sequence of 
swaps if / o occurs before jf>l. 
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o:C[C'[{mi:Si} ie i]f,Tg]*o > g <-> /.TOj(); switch (g <-> null) {Z: ei} leE 

I (R-Call) 

o : C[C'[F] f,T g] *o.f > go return e: switch (go null) {I: ei}i eE 

I* 

o : C[C'[F lo ] f,T g]*o.f > .g «-> return Z ; switch [g O null) {Z: e/} ;e£; 

4^ (R-Return) 

o:C[C"[S; ] /,Tj]*o > .g «-> Z ; switch (g o null) {Z: e ; } /eE 

I (R-Swap, R-Seq) 

o : <7[<7^Z : SA^s] /, (link /)<?]* o > switch (.g O null) {Z: ei } leE 

I (R-Swap) 

o:C[C'[S lo ] f,Hu\\g]*o > switch (Z ) {Z: e z } /eB 

J, (R-Switch) 

o:C[C'[5, ] /,Null 5 ]*o > e h 

Figure 12: Example of the interplay between method call, switch and link types. The heap and 
the rightmost typing environment are omitted. 

3.5 Example of reduction and typing 

Figure [12] illustrates the operational semantics and the way in which the environment used to type 



an expression changes as the expression reduces (see Theorem 3.18 on page 19 1. 
The initial expression is 

9 = f-mjQ; switch (5) {I: e t }i eE 
where for simplicity we have ignored the parameter of rrij . This expression is an abbreviation for 

g «-> /.TOj(); null; switch (g <-» null) {I: ei} teE 

which we simplify to 

g «-> f.rrijO; switch (g «-> null) {Z: e/}; 6£ ; 
The initial typing environment is 

o : C[C[{m : Si} ieI ] f,Tg] 
with o as the current object, where Sj = (I : Si)i<= E . The body of method Wj is e with the typing 
this : C'[F] * this D> e : linkthis < this : C'[(l : F z ) ZeB ] * this 



and we assume that mj returns Iq G E. According to Definition 3.12 and the typing of the 
declaration of class C we have Fi h C" : Si and F h C" : {rni : Si}i^j. 

The figure shows the environment in which each expression is typed; the environment changes 
as reduction proceeds, for several reasons explained below. The typing of an expression is T > 
e : T < r' but we only show T because V does not change and T is not the interesting part of 
this example. We also omit the heap, showing the typing of expressions instead of states. Calling 
f-mj() changes the type of field / to C'[F] because we are now inside the object; the current 
object path changes from o to o.f. As e reduces to Iq the type of / may change, finally becoming 
C'[Fi ] so that it has the component of the variant field typing (Z : Fi)i eE corresponding to Iq. The 
reduction by R- Return changes the type of / to CfSiJ because we are now outside the object 
again, but the type is still the component of a variant typing corresponding to Iq. At this point / 
is popped from the current object path. The swap changes the type of / again, to C'[(l : Si)i &E ], 
which is C'[Sj], the type we were expecting after the method call. At this point the information 
about which component of the variant typing we have is stored in o.g, the field the label was 
swapped into: the type of the expression f.rrijQ is link /, which appears as the type of o.g after 
the swap is executed. When extracting the value of g in order to switch on it, the type link / 
disappears from the environment and becomes the type of the subexpression g 4-> null, at the same 
time resolving the variant type of / according to the particular enumerated value Iq. 
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3.6 Typing the initial state 

Recall the discussion of the initial state for execution of a program, from the end of Section |3.2| 
The initial state is (top = C[C.fields = null] *top; e) where class C has a designated main method 
m with body e. In order to type this initial state, we require that m is immediately available in 
C.session, and assume that the program is typable, i.e. that rule T-Class is applicable to every 
class definition. If C.fields = / then the hypothesis of T-Class is Nuii f h C : C.session; this 
is what the type checking algorithm defined in Section [8] checks. The definition of F h C : S 
gives this : C[Null /], x : Null * this t> e : T < this : C[F] * this for some field typing F. The type 

(Substitution), to be proved later, gives top : C[Null/] * top > e : 



7.10 



T is irrelevant. Lemma 

T < top : C[F] * top, as we assumed that e{ nu "/ a; } = e. Straightforward use of T-HEmpty and 
T-HAdd gives h top = C[C.fields = null] : top : CfNull f] and then T-State gives a typing for the 
initial state. 

3.7 Properties of the type system 

The main results in this sequential setting are standard: type preservation under reduction (also 
known as Subject Reduction) and absence of stuck states for well-typed programs. Furthermore, 
the system also enjoys of a conformance property: all executions of well-typed programs follow 
what is specified by the classes' session types. 

3.7.1 Soundness of subtyping 

In this section we prove that the subtyping relation is sound with respect to the type system, in 
the sense that it preserves not only typing judgements but also consistency between field typings 
and session typings, reflecting the safe substitution property. 

Lemma 3.14 If T * r > e : T < V * r' and V" <: T, then V" * r > e : T < V * r' . 
Proof. Straightforward induction on the derivation. 

Proposition 3.15 (soundness of subtyping for fields) If F H C : S and F' <: F then F' h 

C:S. 



Proof. Straightforward using Lemma |3.14| 

Before proving the case where subtyping is on the right, we first remark that, similarly to 



sub-session, the necessary conditions in the definition of C-consistency (Definition 3.12) become 
sufficient once we consider the largest relation: 

Lemma 3.16 Let C be a class and F a field typing for that class. 

1. Suppose F is not a variant, and suppose there is a set of method definitions {rriiixi) {ei}}igj 
in the declaration of class C such that, for all i, we have this : C[_F], Xi : T[ * this E> e.; : Tj < 
this : C[Fi] * this with F { h C : 5*. Then F h C : {T 4 m^T!) : S^g/ holds. 

2. Suppose F — (I : Fi)i^e' an d ^ (^)ieB ^ e a family of session types such that E' C E and 
Fi^C : Si for all I G E' . Then F h C : (I : Si) ieE holds. 

Proof. Let S be either {Ti mi(T[) : Si}i^i or (I : Si)i^e depending on the case. Just notice that 
(• h C : •) U {(F, S)} is a C-consistency relation. 

Proposition 3.17 (soundness of subtyping for sessions) // F h C : S and S <: S' then 
FhC:5'. 

Proof. For any class C, we define the following relation: 

TZ C = {(F, S')\3S,FhC:S and S <: 5"} 



and prove that it is a C-consistency relation (Definition 3.121. Let {F,S') € 72-Cj and let S be as 
given by the definition of the relation. We have two cases depending on the form of S' (branch or 
variant). 



18 



The first one is S' = {C/j mj(Tj) : S'j}j eJ . Then S <: S' means (Definition that we 
have: 5 = {Z7j TOj(Tj) : S^}^/ with J C 7 and for all j G J, [Tj nij(Tj) : Sj is < :-compatible 
with f/j mj(Tj) : S^. Let j € J, we know from Fh C: S that C contains a method declaration 
rrij(x) {e} such that the following judgement: 

x : Tj, this : C[F] * this t> e : Uj < this : C[Fj-] * this 



holds, with Fj h C : Sj. < ^compatibility between the two signatures of m,j (Definition 3.4 1 gives 
us, first, Tj <: Tj, which allows us to apply Lemma 3.14 to this judgement and replace Tj by Tj 
in it, and second, either: 

1. Uj <: Uj and Sj <: Sj. The former allows us to use T-Sub to replace Uj by [Tj in the typing 
judgement for e, fulfilling the first condition in the definition of C-consistency. The latter, 
together with Fj\- C : Sj, implies {Fj, Sj) £ TZc, fulfilling the second one. 

2. Uj is an enumerated type E, Uj = linkthis and (I : Sj)i^E <■ Sj. In this case we first apply 
T-VarF to the judgement, yielding: 

x : T', this : C[F] * this > e : linkthis < this : C[(l : F ) leE ] * this. 



From Fj h C : Sj we deduce (I : Fj)i e E \~ C : {I : Sj)i^E using Lemma 3.16 and conclude 
((l:F j ) leE ,S' j )£ll c . 

In the second case, where S' = (I : S[)i e E'- then S = {I : Si)i e e with E £ E' and V7 £ E, Si <: 
S'f. From F h C : S we know that F = (I ; Fi) leE " with E" C E and F l h C : Si for any I in E" . 
Just notice that £"' C E' and (F, S*;) £ K c for any / in E". 

3.7.2 Type preservation 

Theorem 3.18 (Subject Reduction) Let V be a set of well-typed declarations, that is, such 
that for every class declaration D in T> we have h D. 

If, in a context parameterised by T>, we have V * r > (h * r; e) : T < T' * r', and z/ (h*r; e) — ^ 
(/i' * r"; e'), t/ien f/iere exists T" such that F" * r" > (/i' * r"; e') : T < V * r' . 

Proof. This theorem is a particular case of Theorem |7.16| which will be proved in Section [7] 

3.7.3 Type safety 

Theorem 3.19 (No Stuck Expressions) LefD be a set of well-typed declarations, that is, such 
that for every class declaration D in T> we have h D. 

If, in a context parameterised by T>, we have T * r > [h * r; e) : T < V * r', i/ien either e is a 
value or there exists (h 1 * r" ; e') such that (h * r; e) — >• (/i' * r"; e'). 

Proof. This theorem is also a consequence of Theorem |7.16| so we postpone its proof until Section 

3.7.4 Conformance 

We show that, in well-typed programs, a sequence of method calls (interleaved with their respective 
return labels) of a given class is a path of its session type. In order to state this property precisely, 
we introduce a few definitions. 

Definition 3.20 (Call trace) A call trace is a sequence m,\l\m,il2 ■ ■ ■ mrJ-n in which each m,i is 
a method name and each li may be absent or, if present, is a label. 

Definition 3.21 (LTS on session types) Define a labelled transition relation on class session 
types by the following rules, a stands for m or I. 

j£l l £E 



{T! rmiTi) : S,}ie/ Sj (I : S t ) 



ieE 



S is not a variant S{ llX S /x} S' 

S^S vX.S^S* 
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Definition 3.22 (Call trace mapping) A call trace mapping for a heap h is a function tr from 
dom(h) to call traces. 

Definition 3.23 (Validity of mappings) A call trace mapping tr for a heap h is valid if for 

tr(o) 

every entry o = C[. . .] in h, we have C.session — >* . An element in a call trace which does not 
allow the corresponding session type to reduce is a type error. (Thus a call trace is valid if and 
only if it does not contain type errors). 

Definition 3.24 If tr is a call trace mapping for a heap h then we define tr(h, r) for references 
r such that h(r) is defined, as follows: 

tr(h, o) = tr(o) 
tr(h,r.f) = tr(h(r).f) 

Definition 3.25 (Original reduction rule) If(h*r; e) — > (hi *r'; e') then the derivation of 
this reduction consists of a number of applications of R-CONTEXT, preceded by another rule which 
forms a unique leaf node in the derivation. We say that the rule at the leaf node is the original 
reduction rule for the reduction, or that the reduction originates from this rule. 

Definition 3.26 (Extension of call traces) Suppose tr is a call trace mapping for h and (h * 
r; e) — > (h 1 * r'; e'). Define a call trace mapping tr' for h' as follows: 

• If the reduction originates from R-Call with method m and field f then tr' — tr{h(r.f) i— > 
tr(h(r.f))m\. 

• // the reduction originates from R-RETURN with value v, and v is a label I, then tr' = 
tr{h(r) i-» tr(h(r))l}. 

• // the reduction originates from R-New and the fresh object is o then tr' = tr{o i— > e}. 

• Otherwise, tr' = tr. 

The conformance property is the following: in a sequence of reductions starting from the initial 
state of a well-typed program, the call traces built using the extension mechanism defined above 
are valid throughout the sequence. We need a couple of lemmas to properly relate call traces and 
typings in the case of variant types. 

Lemma 3.27 If\~h:T, then T does not contain type linkthis or any variant field typing. 

Proof. It suffices to show that rule T-VarF cannot be used in the derivation of H h : T, since it 
is the only rule that introduces linkthis or variant field typings. 

This rule can only be used on an expression of enumerated type, and the only place where such 
an expression can occur in the derivation of h h : T is as the right member of a swap in the second 
premise of T-Hadd (the swap expression itself has type Null because of the initial environment). 
It corresponds to the first premise of T-Swap. However, the third premise of T-Swap forbids 
that the type of the expression be linkthis, hence T-VarF cannot be used there. 

Lemma 3.28 (Variant consistency) If\~h:T and T(r) = (I : Si)i^e, then: 

1. r is of the form r'.f 

2. there exists f such that T(r'.f) = link / and h(r'.f') e E. 

Proof. Consider how a variant session type can be introduced in the derivation of h h : T. Because 
of Lemma [3. 2 7| it cannot be a consequence of T-Hide: indeed, F h C : S where S is a variant 
can only hold if F is a variant as well. Thus the only possibility is T- VarS , and it can only occur 
when typing one of the values in the right premise of T-Hadd. (1) follows from the fact that 
T-VarS acts on a field of the current object. Then T-SubEnv can be applied but the original 
label T-VarS was applied to is still in the final E. (2) follows from the structure of the derivation: 
the label T-VarS is applied to is then swapped into a field of the same object. 
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Top-level syntax (add to Figure [5j: 

e ::= ... | while (e) {e} 

Reduction rule (add to Figure ml: 

(R- While) (h * r; while (e) {e'}) — > (h * r; switch (e) {True : e'j while (e) {e'}, False : null}) 
Top-level typing rules (add to Figure |9j: 

r * r > e : {True, False} < T' * r' T' * r' > e' : Null < T * r 



(T-While) 



r * r > while (e) {e'} : Null < T' * r' 



F*r>e: link / < V *r' r'(r'.f) = (True : SYrue, False : 5 Fa | S e> 

V'lr'.f h> S Tm <.} * r' > e' : Null < V * r 

T-WhileLink) 1 — — 

r * r > while (e) {e'} : Null < T'{r'.f h-> S False } * r' 

Figure 13: Rules for while 

Definition 3.29 (Actual session type) Let Y and h be such that h h : T. For any r in T such 
that r(r) is a session type S, we define S' , the actual session type of r in h according to Y , as 
follows: 

• If S is a branch then S' = S. 



If S is a variant (I : Si)i^e> then 5" = S^^i frj, where r' and f are as given by Lemma 
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Definition 3.30 (Consistency of call traces) Let tr be a call trace mapping for a heap h and 
let r be a type environment such that h h : T. We say that tr is consistent with T if for every r 

tr(h,r) 

in r with actual session type S we have class(/i(r)). session — 5-* S. 

Theorem 3.31 (Conformance) Suppose we are in a context parameterised by a set of well-typed 
declarations. 

Let (hi * r\] e{) be a program state together with a valid call trace mapping tr\, and suppose 
that (h\ * n; e±) — > ■ ■ ■ — > (h n * r n ; e n ) is a reduction sequence such that r\ is a prefix of all 
r.i. Definition \3. 26\ gives a corresponding sequence of call traces tri. 

If there exists T such that tr\ is consistent with Y and Y * r\ > (h\ * r\\ ei) : T < Y' * r' then 
for all i, tri is valid. 

Proof. Postponed, again, to Section [7] as it makes use of the proof of Theorem |7. 16| which will 
be proved there. 

Corollary 3.32 Given a well-typed program, starting from the initial state described at the end 



of Section 3.2 with the initial call trace mapping {top t— > m}, and given a reduction sequence 
from there, the call trace mappings obtained by Definition \3. 2(\ following the reductions are valid 
throughout the sequence. 

Proof. We just have to see that: 

1. the initial call trace mapping is valid, as the main method m is required to appear in the 
initial session type of the main class; 



2. it is also consistent with the initial typing given in Section 3.6 as the initial Y contains no 
session type; 

3. the initial current object path is reduced to an object identifier and, therefore, stays a prefix 
of the current object path throughout any reduction sequence. □ 



4 Extensions to the Sequential Language 

This section describes some extensions of the core language presented in the previous section. 
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Top-level syntax (add to Figure [5| : 

M ::= ... | req F ens F for T m(T x) {e} 

e ::= ... | m(e) 

Reduction rule (add to Figure [tJ: 

req _ ens _ for _ m(_x) {e} £ /i(r). class 



(R-SelfCall) 



(h * r; m(v)) — > (h * r; e{ v / x }) 
Top-level typing rules (add or replace in Figure |5J: 

r*r > c e:T<T'*r' r'(r') = C[F] req F ens F' for T' m(T x) {e} e C 



(T-SelfCall) 



(T-AnnotMeth) 



r * r > c m(e) : T" < r'{r' >-> C[F']} * r' 
this : C[F],x : T' * this > c e : T < this : C[F'],z : T" * this F' ^ (_) 



(T-Class) 



h c req F ens F' for T m(T' x) {e} 
Nufi / h C : S VM 6 M. (M has req/ens => h c M) 



h class C {S;f;M} 



Figure 14: Rules for recursive methods and other self-calls 



4.1 While Loops 

The language can easily be extended to include while loops, by adding the rules in Figure[l3] The 
reduction rule defines while recursively in terms of switch. There are two typing rules, derived 
from T-Switch and T-SwitchLink. The first deals with a straightforward while loop that has 
no interaction with session types, and the second deals with the more interesting case in which 
the condition of the loop is linked to the session type of an object. 



4.2 Self-Calls and Recursive Methods 



The rules in Figure 14 extend the language to include self-calls (method calls on this). This 
extension also supports recursive calls, which are necessarily self-calls. Self-calls do not check or 
advance the session type, and a method that is only self-called does not appear in the session type. 
A method that is self-called and called from outside appears in the session type, and calls from 
outside do check and advance the session type. The reason why it is safe to not check the session 
type for self-calls is that the effect of the self-call on the field typing is included in the effect of the 
method that calls it. All of the necessary checking of session types is done because of the original 
outside call that eventually leads to the self-call. 

Because they are not in the session type, self-called methods must be explicitly annotated 
with their initial (req) and final (ens) field typings. The annotations are used to type self-calls 
(T-SelfCall) and method definitions (T-AnnotMeth). The result type and parameter type 
are also specified as part of the method definition, again because the method is not in the session 
type. 

If a method is in the session type then its body is checked by the first hypothesis of T-Class, 
but the annotations (if present) are ignored except when they are needed to check recursive calls. 
If a method has an annotation then its body is checked by the second hypothesis of T-Class. If 
both conditions apply then the body is checked twice. An implementation could optimize this. 

An annotated method cannot produce a variant field typing or have a link type, because 
T-SwitchLink can only analyze a variant session type, not a variant field typing. 



4.3 Shared Types and Base Types 

The formal language described in this paper has a very strict linear type system. It is straight- 
forward to add non-linear classes as an orthogonal extension: they would not have session types 
and their instances would be shared objects, treated in a completely standard way. Our prototype 
implementation, described in Section [8.4| includes them, but including them in the formalisation 
would only complicate the typing rules. 
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FileReadCh = &{OPEN : ? S t r i n g . ©{OK : OpenCh , ERROR: FileReadCh}, QUIT: End} 1 

OpenCh = &{HASNEXT: ©{TRUE : CanReadCh , FALSE: MustCloseCh } , CLOSE: FileReadCh} 2 

MustCloseCh = &{CLOSE: FileReadCh} 3 

CanReadCh = &{READ : I S t r i n g . OpenCh , CLOSE: FileReadCh } 4 

Figure 15: Remote file server version 1: channel session type (server side) 

More interesting, and more challenging, is the possibility of introducing a more refined approach 
to aliasing and ownership, for example along the lines of the systems discussed in Section [9] We 
intend to investigate this in the future. 

Base types such as int are also straightforward to add, and would be treated non-linearly. 

4.4 Nominal Subtyping 

The formal language uses a structural type system in which class names are only used in order 
to obtain their session types; method availability is determined solely by the session type, and 
method signatures are also in the session type. In particular, the subtyping relation is purely 
structural and makes no reference to class names. It is straightforward to adapt the language 
to include features associated with nominal subtyping, such as an explicitly declared inheritance 
hierarchy for classes with inheritance and overriding of method definitions. In this case, if class C 
is declared to inherit from class D, and both define session types (alternatively, C might inherit 
its session type from D), then the condition C.session <: D. session would be required in order for 
the definition of C to be accepted. 

5 A Distributed Example 

We now present an example of a distributed system, illustrating the way in which our language 
unifies session-typed channels and more general typestate. The scenario is a file server, which 
clients can communicate with via a channel. The file server uses a local file, represented by a 
File object as defined in Section [2] and responds to requests such as OPEN and HASNEXT on 
the channel. On the client side, the remote file is represented by an object of class RemoteFile, 
whose interface is similar to File . In this "stub" object, methods such as open are implemented 
by communicating with the file server. 

The channel between the client and the server has a session type in the standard sense, which 
defines a communication protocol. In our language, each endpoint of the channel is represented 
by an object of class Chan, with a class session type derived from the channel session type. This 
class session type also expresses the definition of the communication protocol, by specifying when 
the methods send and receive are available. 

For the purpose of this example, we imagine that the communication protocol (channel session 
type) is defined by the provider of the file server, while the class session type of RemoteFile is defined 
by the implcmentor of a file system API. We therefore present two versions of the example: one in 
which the channel session type, and the class session type of RemoteFile, have the same structure; 
and one in which they have different structures. 

5.1 Distributed Example Version 1 

Figure [15] defines a channel session type for interaction between a file server and a client. The type 
of the server's endpoint is shown, and the type FileReadCh is the starting point of the protocol. 
The type constructor & means that the server offers a choice, in this case between OPEN and 
QUIT; the client makes a choice by sending one of these labels. If OPEN is selected, the server 
receives (constructor ?) a String and then (the . constructor means sequencing) the constructor © 
indicates that the server can choose either OK or ERROR. The remaining definitions are read in 
the same way; note that End means termination of the protocol. The type of the client's endpoint 
is dual, meaning that receive (?) and send (!) are exchanged, as are offer (&) and select (©). 
When the server offers a choice, the client must make a choice, and vice versa. 
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FileRead_cl ={Null send ( {OPEN }) : {Null send ( Stri ng ) : {{OK, ERROR} receive(): 1 

(OK: Open_cl , 2 
ERROR: Fi I e Read _ c I > }} , 3 

Null send({QUIT}): {}} 4 

where 5 

Open cl = {Null send ({HASNEXT} ) : {{TRUE, FALSE} receiveQ: 6 

(TRUE: CanRead cl , FALSE: M u st C I ose _ c I ) } , 7 

Null send ({CLOSE}) : FileRead_cl} 8 

MustClose_cl = {Null send ( {CLOSE }) : FileRead_cl} 9 

CanRead_cl = {Null send ( {READ }) : {String receiveQ: Open_cl}, 10 

Null send({CLOSE}): FileRead_cl} 11 

FileRead_s = {{OPEN, QUIT} receiveQ: (OPEN: {String receive(): 1 

{Null send({OK}): Open_s, 2 
Null send ({ERROR}): FileRead_s}, 3 

QUIT: {}>} ' 4 

where 5 

Open_s = {{HASNEXT, CLOSE} receive (): 6 

(HASNEXT: {Null send ({TRUE}) : CanRead_s, 7 

Null send ({FALSE}) : MustClose_s} , 8 

CLOSE: FileRead_s}} 9 

MustClose_s = {{CLOSE} receiveQ: (CLOSE: FileRead_s}} 10 

CanRead_s = {{READ, CLOSE} receiveQ: (READ: {Null send ( S t r i n g ) : Open_s}, 11 

CLOSE: FileRead_s)} 12 

Figure 16: Remote file server version 1: client and server class session types generated from channel 
session type FileReadCh 

class RemoteFile { 1 

session {connect: Init} 2 

where Init = {open: (OK: Open, ERROR: Init}} 3 

Open = {hasNext: (TRUE: Read, FALSE: Close), close: Init } 4 

Read = {read: Open, close: Init } 5 

Close = {close: Init } 6 

7 

channel; 8 

9 

Null con nect ( ( Fi leRead Ch ) server) { 10 

channel = s e r v e r . req u est ( ) ; 11 

} 12 

{OK, ERROR} open (String name) { 13 

channel . send (OPEN) ; 14 

c ha n nel . send ( name ) ; 15 

switch ( ch a n ne I . recei ve ( ) ) { 16 

OK: OK; 17 

ERROR: ERROR; 18 

} 19 

} 20 

{TRUE, FALSE} hasNext () { 21 

channel . send (HAS_NEXT) ; 22 

switch (channel. receiveQ) { 23 

TRUE: TRUE; 24 

FALSE: FALSE; 25 

} 26 

} 27 

String readQ { 28 

channel . send (READ) ; 29 

c h a n nel . recei ve () ; 30 

} 31 

Null closeQ { 32 

channel . send (CLOSE) ; 33 

} 34 

} 35 

Figure 17: Remote file server version 1: client side stub 
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classFileServer{ 1 

session { Null main ( { Fi leRead Ch } port): {} } 2 

3 

channel; file; 4 

5 

Null main ( { FileRead _c } port) { 6 

file = new F i I e ( ) ; 7 

channel = po rt . accept () ; 8 

fileRead (); 9 

} 10 

req FileRead_s channel , Init file 11 

ens {} channel , Init file 12 

Null fileRead () { 13 

switch ( ch a n nel . receive () ) { 14 

OPEN: 15 

switch ( f i I e . open ( ch a n n e I . recei ve ( ) ) ) { 16 

OK: open(); 17 

ERROR: fileRead () ; 18 

} 19 

QUIT: null; 20 

} 21 

} 22 

req Open_s channel , Open file 23 

ens {} channel, Init file 24 

Null open() { 25 

switch (channel. receive()){ 26 

HASNEXT: 27 

switch ( f i I e . hasNext ( ) ) { 28 

TRUE: channel . send (TRUE) ; canRead(); 29 

FALSE: ch a n nel . send ( FALSE ) ; mustClose(); 30 

} 31 

CLOSE: file, close ( ) ; fileReadQ; 32 

} 33 

req MustClose_s channel , Close file 34 

ens {} channel , Init file 35 

Null mustClosef) { 36 

switch ( ch a n nel . recei ve ( ) ) { 37 

CLOSE: f i I e . close ( ) ; fileRead(); 38 

} 39 

} 40 

req CanRead_s channel , Read file 41 

ens {} channel, Init file 42 

Null canReadf) { 43 

switch (channel. receive()){ 44 

READ: ch a n nel . send ( f i I e . rea d ( ) ) ; open(); 45 

CLOSE: file . close (); fileRead(); 46 

} 47 

} 48 

} 49 



Figure 18: Remote file server version 1: server code 



The structure of the channel session type is similar to that of the class session type of File 
from Section [2] in the sense that HASNEXT is used to discover whether or not data can be read. 

We regard each endpoint of a channel as an object with send and receive methods. For every 
channel session type there is a corresponding class session type that specifies the availability and 
signatures of send and receive. The general translation is defined in Section [6] Figure 25 For the 



particular case of FileReadCh, the client and server class session types are as defined in Figure 16 
(using Style 2 since the signatures vary and there is no associated class declaration). 

Selecting one option from a range (©) corresponds to availability of send with a range of 
signatures, each with a parameter type representing one of the possible labels; here we are taking 
advantage of overloading, disambiguated by parameter type. Offering a choice (&) corresponds 
to a receive in which the subsequent session depends on the label that is received. Sending and 
receiving data correspond straightforwardly to send and receive with appropriate signatures. 
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FileChannel = &{OPEN : ? S t r i n g . 0{OK : CanRead , ERROR: FileChannel }, QUIT: End} 1 
CanRead =&{READ: 0{EOF: FileChannel, DATA: ! S t r i n g . Ca n Read } , CLOSE: FileChannel} 2 



Figure 19: Remote file server version 2: channel session type (server side) 



ClientCh ={Null send ( {OPEN }) : {Null send ( S t r i n g ) : {{OK, ERROR} receive(): 1 

(OK: CanRead_cl , 2 

ERROR: ClientCh)}}, 3 

Null send({QUIT}): {}} 4 

where CanRead_cl = {Null send ({READ} ) : {{EOF, DATA} receive(): 5 

(EOF: ClientCh , 6 
DATA:{String receive(): CanRead_cl}) } , 7 

Null send ({CLOSE}) : ClientCh} 8 

ServerCh = {{OPEN, QUIT} receive (): (OPEN: {String receive (): 1 

{Null send({OK}): CanRead_cl, 2 

Null send ( {ERROR} ) : ServerCh}}, 3 

QUIT: {})} 4 

where CanRead_cl = {{READ, CLOSE} receive (): 5 

(READ: {Null send({EOF}): ServerCh , 6 
Null send ({DATA)}: { Null send ( S t r i n g ) : CanRead_cl }} , 7 

CLOSE: ServerCh)} 8 



Figure 20: Remote file server version 2: client and server class session types generated from channel 
session type FileChannel 



Figure 17 defines the class RemoteFile, which acts as a local proxy for a remote file server. Its 
interface is similar to that of the class File from Section [2j the only difference is that RemoteFile 
has an additional method connect, which must be called in order to establish a connection to 



the file server. The types RemoteFile. Init and File . Init are equivalent (Definition 3.9 1: each is a 
subtype of the other, and they can be used interchangeably. 

The methods of RemoteFile are implemented by communicating over a channel to a file server. 
The connect method has a parameter of type (FileReadCh). A value of this type represents an 
access point, analogous to a URL, on which a connection can be requested by calling the request 
method (line 11); the resulting channel endpoint has type FileRead_cl. 

The remaining methods communicate on the channel, and thus advance the type of the field 
channel. The similarity of structure between the channel session type FileReadCh and the class 
session type Init is reflected in the simple definitions of the methods, which just copy information 
between their parameters and results and the channel. There is one point of interest in relation 
to the close method. It occurs three times in the class session type, and according to our type 
system, its body is type checked once for each occurrence. Each time, the initial type environment 
in which the body is checked has a different type for the channel field: Open cl, MustClose_cl or 
CanRead_cl. Type checking is successful because all of these types allow send({CLOSE}). 



Figure 18 defines the class FileServer , which accesses a local file system and uses the server 
endpoint of a channel of type FileReadCh. The session type of this class contains the single method 
main, with a parameter of type (FileReadCh). We imagine this main method to be the top-level 
entry point of a stand-alone application, with the parameter value (the access point or URL for 
the server) being provided when the application is launched. The server uses accept to listen 
for connection requests, and when a connection is made, it obtains a channel endpoint of type 
FileRead_s. 

The remaining methods of FileServer are mutually recursive in a pattern that matches the 
structure of FileReads. The methods are self-called, and do not appear in the class session type; 
instead, they are annotated with pre- and post-conditions on the types of the fields channel and 
file . The direct correspondence between the structure of the channel session type and the class 
session type of File is again reflected in the code, for example on lines 29 and 30 where the result 
of calling hasNext on file directly answers the HASNEXT query on channel. 



2G 



class RemoteFile { 1 

session {connect: Init} 2 

where Init = {open: (OK: Open, ERROR: Init)} 3 

Open ={hasNext: (TRUE: Read, FALSE: Close), close: Init} 4 

Read = {read: Open, close: Init} 5 

Close = {close: Init} 6 

7 

channel; state; 8 

9 

Null con nect ( ( Fi leC ha n nel ) c) { 10 

channel = c . request () ; 11 

} 12 

{OK, ERROR} open (String name) { 13 

channel . send (OPEN) ; 14 

c h a n n e I . send ( name ) ; 15 

switch ( ch a n nel . receive () ) { 16 

OK: state = READ; OK; " 17 

ERROR: ERROR; 18 

} 19 

} 20 

{TRUE, FALSE} hasNext() { 21 

channel . send (READ) ; 22 

switch ( ch a n nel . receive () ) { 23 

EOF: state = EOF; FALSE; 24 

DATA: state = DATA; TRUE; 25 

} 26 

} 27 

String read() { 28 

state = READ; 29 

channel, receive (); 30 

} 31 

Null closeQ { 32 

switch (state) { 33 

EOF : n u 1 1 ; 34 

READ: channel . send (CLOSE) ; 35 

DATA: ch a n ne I . recei ve ( ) ; c h a n n e I . send ( CLOSE ) ; 36 

} 37 

} 38 

} 39 



Figure 21: Remote file server version 2: client side stub 



5.2 Distributed Example Version 2 



This version has a different channel session type, FileChannel, defined in Figure 19 which does not 
match the class session type FileRead. The difference is that there is no HASNEXT option; instead, 
the READ option is always available. If there is no more data then EOF is returned in response 
to READ; alternatively, DATA is returned, followed by the desired data. The corresponding class 
session types for the client and server endpoints are defined in Figure [20] 

The implementation of RemoteFile must now mediate between the different structures of the 
class session type FileRead and the channel session type FileChannel. The new definition is in 



Figure 21 The main point is that the definition of the close method must depend on the state of 
the channel. For example, if close is called immediately after a call of hasNext that returns TRUE, 
then the channel session type requires data to be read before CLOSE can be sent. We therefore 
introduce the field state, which stores a value of the enumerated type {EOF, READ, DATA}. This 
field represents the state of the channel (equivalently, the session type of the channel field): EOF 
corresponds to ClientCh, READ corresponds to CanRead, and DATA corresponds to the point after 
the DATA label in CanRead. The definition of close contains a switch on state, with appropriate 
behaviour for each possible value. It is also possible for state to be null, but this only occurs 
before open has been called, and at this point close is not available. 

In order to type check this example we take advantage of the fact that the body of the close 
method is repeatedly checked, according to its occurrence in the class session type. The value of 
state always corresponds to the state of channel. This correspondence is not represented in the 
type system — that would require some form of dependent type — but whenever the body of close 
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classFileServer{ 1 

session {main: {}} 2 

3 

channel; file; 4 

5 

Null main ( { FileCha nnel } c) { 6 

file = new F i I e ( ) ; 7 

channel = c.acceptQ; 8 

serverCh(); 9 

} 10 

req ServerCh channel , Init file 11 

ens {} channel , Init file 12 

Null serverCh () { 13 

switch ( ch a n ne I . recei ve ( ) ) { 14 

OPEN: 15 

switch ( f i I e . open ( ch a n n e I . recei ve ( ) ) ) { 16 

OK: canReadQ; 17 

ERROR: serverCh () ; 18 

} 19 

QUIT: null; 20 

} 21 

} 22 

req CanRead_s channel , Open file 23 

ens {} channel, Init file 24 

Null canReadf) { 25 

switch (channel. receive()){ 26 

READ : 27 

switch ( f i I e . hasNext ( ) ) { 28 

TRUE: channel . send (DATA) ; c h a n n e I . send ( f i I e . rea d ( ) ) ; 29 

canRead(); 30 

FALSE: ch a n nel . send ( EOF ) ; f i I e . c I o s e ( ) ; serverCh(); 31 

} 32 

CLOSE: file, close ( ) ; se rve rC h ( ) ; 33 

} 34 

} 35 



Figure 22: Remote file server version 2: server code 

is type checked, the type of channel is compatible with the value of state, and so typechecking 
succeeds. More precisely, each possible value of state corresponds to a different singleton type 
for state (typing rule T-Label), and rule T-SwiTCH only checks the branches that correspond 
to possible values in the enumerated type of the condition. So each time the body of close is 
type checked, only one branch (because the type of state is a singleton) of the switch is checked, 
corresponding to the value of state for that occurrence of close . 

6 A Core Distributed Language 

We now define the core of the distributed language illustrated in Section [5] For the top-level lan- 
guage, the only additions are the access points and their types (T), channel session types and their 
translation to class session types, and the spawn primitive. However, there are significant changes 
to the internal language, in order to introduce a layer of concurrently executing components that 
communicate on channels. 

6.1 Syntax 

Figure [23] defines the new syntax. The types of access points are top-level declarations. Of the 
new values, access points n can appear in top-level programs, but channel endpoints c are part 
of the internal language. The spawn primitive was not used in the example in Section [5j but 
its behaviour is to start a new thread executing the specified method on a new instance of the 
specified class. Although a parameter is required as in any method call, for simplicity the type 
system restricts the parameter's type to be Null in this case, so that there is only one form of 
inter-thread communication. The syntax of channel session types £ is included so that the types 
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Declarations 


D 


:= ... 


access (E) n 




Values 


V 




c + | c~ | n 




Expressions 


e 




spawn C.m(e) 




Contexts 


£ 




spawn C.m(£) 




Channel session types 


E 


:= end | 


X | fiX.T, | ? 


[T] . E | 






1 


2ih SE 1 e{« 




States 


s 




s || s | (vc) s 





Figure 23: Additional syntax for channels and states 

Structural congruence: 

Sl || s 2 = S 2 || Si si || (s 2 || s 3 ) = (si || s 2 ) || s 3 



Reduction rules: 
(R-Init) - 

(R-ComBase) 



si || (vc)s2 = (uc)(si || S2) if c~^,c not free in si 



h( r )-f = n h' (r').f' = n c fresh 



(E-Comm,E- Assoc) 
(E-Scope) 



(ft * r; £[/.accept()]) || (ft' * r'; £'[/'. request()]) — > (uc) ((ft * r; f[c+]) || (ft' * r'; £'[c~])) 

h(r).f = C P h'(r').f' = C P v^O 

(h*r; £[f.send(v)])\\(h' *r'; £'[/'. receive()]) — > (ft * r; 5[null]) || (ft' * r'; f'[u]) 

h(r).f = cP h'(r').f' = cP tp e lnj(dom(ft 4. o),0 \ dom(h')) 



(R-ComObj) 



(R-Spawn) 



(ft*r; £[/.send(o)]) || (ft'*r'; £'[/'.receive()]) — > 

(ftto*r; £[null]) || (ft' + <p(ft 4. o) * r'; £'[v{o)]) 

o fresh Cfields = / m(x) {e} £ C 



(R-Par) 



(ft*r; £:[spawn C.m(t;)]) — > (ft * r; £[null]) || (o = C[/ = null] * o; e{ nu "/4) 
' (R-Str) s = s ' s ' s " s " = s "' (R-NewChan) 



" ^ r. f I I J* 



s\\s 

Top-level typing rules 



(uc) s — > (uc) s' 



(T-Spawn) 



r * r > e : Null < T' * r' Csession = {_ m(Null) :_;...} 

r * r > spawn C.m(e) : Null < V * r' 
access (E) n 

(T-Name) 



r * r > n : [(E)] < T * r 

Figure 24: Reduction and top-level typing rules for concurrency and channels 



of access points can be declared. The syntax of states is extended to include parallel composition 
and a channel binder vc, which binds both c + and c~ in the style of [33 . In a parallel composition, 
the states are exactly states from the semantics of the sequential language; in particular, each one 
has its own heap. This means that spawn generates a new heap as well as a new executing method 
body. Communication between parallel expressions is only via channels. 

The syntax extensions do not include request, accept, send and receive, as they are treated as 
method names. 



6.2 Semantics 



Figure 24 defines the reduction rules for the distributed language, as well as the top-level typing 
rules. The reduction rules make use of a pi-calculus style structural congruence relation, again 
following [33 . It is the smallest congruence (with respect to parallel and binding) that is also 
closed under the given rules. 

Rule R-Init defines interaction between accept and request, which creates a fresh channel c 
and substitutes one endpoint into each expression. 
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There are two rules for communication, involving interaction between send and receive. Rule 
R-ComBase is for communication of non-objects and rule R-ComObj is for communication of 
objects. R-ComBase expresses a straightforward transfer of a value, while R-ComObj also 
transfers part of the heap corresponding to the contents of a transferred object. In R-ComObj, 
ip is an arbitrary renaming function which associates to every identifier in dom(h) an identifier 
not in dom{h!). This rule can easily be made deterministic in practice by using a total ordering 
on identifiers and a mechanism to generate fresh ones. 

R-Spawn creates a new parallel state whose heap contains a single instance of the specified 
class. As discussed above, communication between threads is only through channels in order to 
keep the formal system a reasonable size; therefore, no data is transmitted to the new thread and 
the body of the method being spawned always has its parameter replaced by the literal null. The 
type system will ensure that v — null, so that this semantics makes sense. The remaining rules 
are standard. 

Returning to R-ComObj, there is some additional notation associated with identifying the 
part of the heap that must be transferred; we now define it. First, write O for the set of all object 
identifiers. 



Definition 6.1 Let h be a heap. For any entry o = C[{fi — in h, we define the children 

of o in h to be the set of all Vi which are object identifiers: children/j(o) = {vi \ i € 1} l~l O. 

We say that an object identifier o in dom(h) is a root in h if there is no o' in dom(h) such 
that o € children/jfV). We note roots(/i) the set of roots in h. 

We say that h is complete if for any o in dom(h) we have children^(o) C dom(h). 

If h is complete, we define the descendants of o in h to be the smallest set containing o and the 
children of any object it contains. Formally, let children"(o) = {o} and for i ^ 1, children^o) = 
(J children/,,^). Then desc/j(o) = (J children^o). 

wGchildren^^o) «6N 

Definition 6.2 (Heap separation) Let h be a complete heap and o a root of h. We define h \. o 
to be the sub-heap obtained by restricting h to the descendants of o, and h f o to be the sub-heap 
obtained by removing from h the descendants of o. Note that h \, o is complete and has the property 
that o is its only root. 

Definition 6.3 (Additional notation) • Let h be a heap and let p be a function from O to 
O. We denote by <p(h) the result of applying p> to all object identifiers in h, including inside 
object records. 

• We denote by lnj(A, B) the set of injective functions from A to B. 

• We denote by + the disjoint union of heaps or environments, i.e. the operation h + h! is 
defined by merging h and h! if their domains are disjoint and undefined otherwise. 



6.3 Type System 

The type system treats send, receive, request and accept as method calls on objects whose session 



types are defined by the translations in Figure 25 A channel endpoint with (channel) session 



type £ is treated as an object with (class) session type [£]. The type constructor & (offer) is 
translated into a receive method with return type linkthis in order to capture the relationship 
between the received label and the subsequent type. The type constructor © (select) is translated 
into a collection of send methods with different parameter types, each being a singleton type for 
the corresponding label. 

In a similar but much simpler way, an access type (E) is translated into a (class) session type 
that allows both request and accept to be called repeatedly and at any time. These two methods 
need to return dual channel endpoints, which requires the following definition. 
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Given a channel session type E, define a class session type [E] as follows. 

[end] = {} 

[XI = x 

[/iXE] = fiX.m 

[? [T] . EJ = {T receive(Null) : [E]} 

[! [T] . E] = {Null send(T) : [E]} 

[&{2 : S ; } ieB l = {linkthis receive(Null) : (I : [E,J>, e£ ;} 

[0 {I : £,} ieE J = {Null send(«) : [E ; ]} !e i3 

In the type system, a channel endpoint with session type E is treated as an object with type [E], Calls of send 
and receive are typed as standard method calls. 

Given an access type (E), define a class session type [(E)] by 

[(E)] = fiX.{(S} request(Null) : X, [E] accept(Null) : X}. 

In the type system, an access point with type (E) is treated as an object with type [(E)]. Calls of request and 
accept are typed as standard method calls. 

Figure 25: Object types for channels and access points 

These rules add to or replace the rules in Figure [TT| 

(T-Chan) T,c p :T*r> c p :T <V*r (T-Hempty) 6 h e : [0] 

6 I- h : T T,o : (^[{Null/Ji^^n] * o > /i o vy, ...;/„ O v n : Null < I" * o 



(T-Hadd) 



9 h h, {a = C[{fi = «i}i<i<„]} : r 



(T-Hide) — (T-State) 



© h h : T, o : C[S] 0; r > (h * r; e) : T < T' * r' 

, m m . 0;T > (/i*r; e) : T < V * r' ,- D , 6hs 6'hs' 
(T-Thread) — ^ — ; (T-Par) 



Bh(h*r; e) + 0'hs||s' 

x 0,c+ : E,c" : E h s 

(T-NewChan) — ■ ■ 

9h (uc) s 

Figure 26: Internal typing rules for the distributed language 

Definition 6.4 (Dual channel type) The dual type E of a channel session type E is defined 
inductively as follows: 

end = end 

X = X 
JDcE = ^iXE 
! [T] . E = ? [T] . E 



®{l : E ; } ieB = : E,} 



together with symmetric cases so that E = E. If is sufficient to use this inductive definition, 
rather than a coinductive definition f31^ . because we have adopted the equi-recursive convention 



(Definition 3.9) 



By convention, request returns a channel endpoint of type [E] and accept returns an endpoint of 
type [E]. 

Because access points n are global constants, they can be used repeatedly even though their 
session types are linear; there is no restriction to a single occurrence of a given name. 

The only new typing rules for the top-level language are in Figure |24j T-Spawn allows a 
method to be used in a spawn expression if it is available in the initial session type of the specified 
class. T-Name obtains the type of an access point from its declaration, and assigns an object 
type according to the translation described above. 

Figure [26] contains typing rules for the internal language with the concurrency extensions. 
Rules with the same names as rules in Figure [TT] are replacements. 
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Rule T-Chan takes the type of a channel endpoint from the typing environment. The remain- 
ing rules involve a new typing environment O, which maps channel endpoints to channel session 
types £; these are indeed channel session types, not their translations into class session types. 
T-HAdd, T-Hide and T-State are just the corresponding rules from Figure [TT] with 9 added. 
In T-HEmpty the notation [0] means that the translation from channel session types to class 
session types is applied to the type of each channel endpoint. In combination with T-State, 
this means that the typing of expressions uses class session types for channel endpoints; the T in 
T-Chan is a class session type. 

T-Thread lifts a typed state to a typed concurrent component, preserving only the channel 
typing 0, which is used in T-Par and T-NewChan. In T-Par, + 0' means union, with 
the assumption that and 0' have disjoint domains. T-NewChan requires the complementary 
endpoints of each channel to have dual session types. 

6.4 Subtyping 

We have two subtyping relations between channel session types: £ <: £' as defined in |31| , and 
[E] <: [E'J as defined in this paper. To avoid a detour into the definition of E <: E', we state 
the following result without proof. 

Proposition 6.5 E <: E' [E] <: [E'J. 

Interestingly, the converse is not true, as subtyping between translations of channel session 
types is a larger relation. For example: 

• for all E, IE] <: [end] 

• if E is an enumeration then [? [E] . E] <: : E} ;e£ ] 

• [© {I : E}] = [ ! [{/}] . E] and therefore by transitivity any translated type is a subtype of 
all the corresponding individual translated send types. 

This suggests the possibility, in the context of [31 , of generalizing the subtyping relation 
between channel session types by considering branch/select labels as values in an enumerated 
type. We do not explore this idea further in the present paper. 

7 results 

The key results concerning the distributed language supporting self-calls are, again, Subject- 
Reduction, Type Safety, and Conformance. Notice that we can no longer guarantee the absence 
of stuck states for all well- typed programs, as one endpoint of a channel may try to send when 
the other endpoint is not available to receive. 

7.1 Properties of typing derivations 

This subsection is mostly a collection of lemmas which will be used to prove the main theorems 
in the following ones. They draw various useful consequences from the fact that a program state 
is well- typed. Their proofs can be found in Appendix |10} 

We define chans(/i) as the set of channel endpoints appearing in object records in h. We 
define chans(r) and objs(r) as the sets of, respectively, channel endpoints and object identifiers in 
dom(T). We have dom(T) = chans(r) U objs(r). 

Lemma 7.1 Suppose h h : T. Then (a) h is complete, (b) chans(r) C dom(Q) \ chans(/i) and 
(c) objs(r) C roots(/i). 

Lemma 7.2 (Rearrangement of typing derivations for expressions) Suppose we have 
r*rOe:T<r'*r'. Then there exists a typing derivation for this judgement in which: 

1. T-Sub only occurs at the very end, just before T-Switch or T-SwitchLink as the last 
rule in the derivation for each of the branches, or just before T-Call as the last rule in the 
derivation for the parameter; 
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2. T-SubEnv only occurs immediately before T-SUB in the first three cases and does not occur 
at all in the fourth, i.e. T-CALL. 

Lemma 7.3 (Rearrangement of typing derivations for heaps) Suppose 9 h h : T holds. 
Let o be an arbitrary root of h. Then there exists a typing derivation for it such that: 

1. T-Sub is never used; 

2. T-SubEnv is used at most once, as the last rule leading to the right premise of the last 
occurrence of T-HADD; 

3. every occurrence of T-HlDE follows immediately the occurrence of T-HADD concerning the 
same object identifier; 

4-. the occurrence of T-HADD concerning an identifier d is always immediately preceded (on 
the left premise) by the occurrences of T-Hadd/T-Hide concerning the descendants of d ; 

5. the first root added is o. 

Lemma 7.4 (Splitting of the heap) Suppose h h : T, o : T. Let Q% = \ chans(/i l o) and 

let 92 be 9 restricted to chans(/i \, o). Then we have: ©i I- (h 'f d) : T and O2 \~ (h 4, o) : o : T. 

Lemma 7.5 (Merging of heaps) Suppose 9 h h : T and 0' \- h! : V with dom(h)C\dom{h!) = 
and dom(Q) n dom(&) = 0. Then we have 9 + 9' h h + ti : T + V . 

These two lemmas show, if we apply them repeatedly, that a typing derivation for a heap can 
be considered as a set of separate typing derivations leading to each root of the heap. This will 
allow us in particular to show results for particular cases where a heap has only one root and 
generalize them. 

Lemma 7.6 Suppose h h : o : S. Let ip be an injective function from dom(h) to O. Then we 
have 9 h (p(h) : ip(o) : S. 

Lemma 7.7 (Opening) If h h : T, ifT(r) is a branch session type S and if h(r) is an object 
identifier o, then we know from Lemma \l.l\ that h contains an entry for o. Let C be the class of 
this entry, then there exists a field typing F for C such that h h : T{r 1— > C[-F]} and F h C : S. 

Lemma 7.8 (Closing) IfQhh'.T and T(r) = C[F] and F V- C : S, then Oh h:T{r^ S}. 

Lemma 7.9 (modification of the heap) Suppose that we have 9 h h : T and T * r \> v' : 

T' < r' * r, and that T'(r.f) = T where T is not a variant. Let v = h(r).f . The modified heap 
h{r.f 1— > v'} can be typed as follows: 

1. if v is an object identifier or a channel endpoint, then: 

9 h h{r.f h-> v'} : T'{r.f h-> T'}, v : T 

2. if v is not an object or channel and T is not a link type, then: 

9 h h{r.f h-> v'} : T'{r.f ^ T'} 

3. if v = Iq and T = link then: 

• T'(r.f) = (I : Si)i£E f or some E such that Iq G E and some set of branch session types 
Si. Note that this implies f ' =/= f ' . 

. 9 h h{r.f ^ v'} : T'{r.f ^ T'}{r.f ^ S lo } 

Lemma 7.10 (Substitution) // this : C[F],x : T' * this D> e : T < this : C[F'\ * this, and if 

T(r) = C[F], then: 
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1. if T' is a base type (i.e. neither an object type nor a link) and v is a literal value of that 
type, or if v is an access point name declared with type (S) and [[(£)] <: T' , we have: 

r * r > e{ v / x } : T < T{r h-> C[F'}} * r. 

2. if T' is an object type and v is an object identifier or a channel endpoint, we have: 

r, v : T' * r > e{ v / x } : T <T{r^ C[F']} * r. 

Lemma 7.11 (Typability of Subterms) If V is a derivation ofT*r\> £(e) : T <\V * r' then 
there exist Ti, r\ and U such that T> has a subderivation T>' concluding Y*rl>e:U<\Ti*ri 
and the position of T>' in T> corresponds to the position of the hole in £. 

Lemma 7.12 (Replacement) // 

1. T> is a derivation of Y * r l> £(e) : T <d Y 1 * r' 

2. T>' is a subderivation of T> concluding T * r \> e : U < T± * r\ 

3. the position of T>' in T> corresponds to the position of the hole in £ 

4. r" * r" > e' : u < r x * n 

then T" * r" > £{e') : T < V * r'. 
7.2 Type preservation 

We use h s as an abbreviation for h s; this represents well-typedness of a closed configuration. 
We have the following result: 

Theorem 7.13 (Subject Reduction) //, in a context parameterised by a set of well-typed dec- 
larations, we have h s and s — > s' , then h s' . 

This global result is a consequence of a subject reduction theorem for a single thread, which is 



similar but not identical to what we stated as Theorem 3.18 (which will be a particular case). The 
reason it is not identical is that we need to prove that the type of an expression is preserved not 
only when this expression reduces on its own but also when it communicates with another thread. 
In order to state precisely this thread-wise type preservation theorem, we introduce a labelled 
transition system for threads. Transition labels can be: r indicating internal reduction, c p ! [v] or 
c p ? [v] indicating that the non-object value v is sent or received on channel c p , c p ! [h] or c p ? [h], 
where ft, is a heap with a single root o, indicating that the object o (together with its content) 
is sent or received on channel c p , n[c p ] indicating that the channel endpoint c p is received from 
access point n, or, finally, C.raQ indicating that the thread spawns another one using method m 
of class C. 

Definition 7.14 (Labelled transition system) We define a labelled transition system for threads 
by the following rules: 

(Tr-Red) e)->(V*r>; eQ (Tr _ Send) jW = g _ «gg 

(ft * r; e) (ft' * /; e') (ft * r; f [/.send(u)]) C -^> ] (ft * r; f [null]) 

h(r).f = c p 

(Tr-SendObj) 

(ft*r; f[/.send(o)]) c *" (h \ o * r; f[null]) 

h(r).f = c p v4 
(Tr-Receive — 

(h*r; £[/.receive()]) (ft * r; £[v]) 

ft(r)./ = C p roots(ft') = {o} dom(h) n dom(ft') = 
( R- CV bj) — — 

(h*r; f[/.receive()]) -U J (ft + ft'*r; f[o]) 
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h(r).f = n 

(Tr-Accept) 



(Tr-Request) 



{h*r; f[/.accept()]) (h*r; E[c+}) 

h(r).f = n 

(h*r: £ [/.requestQ]) (h*r; £[c~]) 



(Tr-Spawn) (h*r; £ [spawn C.m(v)}) (h * r; f [null]) 

Note that both r and C.m() correspond to the thread being able to reduce on its own. An important 
feature of this transition relation is that the only case where several different transitions are possible 
from a given state is receive. In all cases including receive, the right-hand state is fully determined 
by the left-hand one and the transition label. 

Definition 7.15 A similar transition relation, with the same set of labels, is defined on channel 
environments as follows: 



e e e e 



n. protocol = (E) Vp, c p £ dom(&) 

e'^ ] e, c +:E 



n. protocol = (E) Vp, ft dom(0) Igl <: T 



n [c~] c p 1 c' p 

6 — -> 6, c- : E 6, : ! [T] .E, c'p' : E' J 6, c?> : E 
gl <: T 

P 7 [ 'P ' ] 

0, c p : ? [T] .E C 0, c p : E, c'p' : E' 
> « : T <J > « : T < 

C P 1 fill c p 7 ful 

6, c p : ! [T] .E — V 0, c p : E 6, c p : ? [T] .E — V 0, c p : E 

lo & E l Q eE 



0, c p : © {Z : E/} ;e£; c -^ o] 9, cp : E, 6, cF : & {I : E,} ieS c -^? 1 9, c p : E io 

0i h h : o : S dom(®i) C chans(/i) 



0! + 2 ,cP : ! [5].E C ^> ] 2 , C p : E 

0' h h : o : S dom(&) C chans(/i) dom(0) n dom(0') = 

0, t* : ? [S] .E c — ^ ] + 0', t* : E 

Where we use > u : T < as an abbreviation for dummy : C[] * dummy > « : T < 
dummy : C[] * dummy — meaning that v is a literal value (or access point name) of type T. 

We can now state our thread-wise type preservation theorem. 

Theorem 7.16 (Thread-wise progress and type preservation) LetD be a set of well-typed 
declarations, that is, such that for every class declaration D in T> we have h D. In a context 
parameterised by T>, suppose we have 0;T > (h * r; e) : T < T' * r'. 

Tften either e is a value or there exists a transition label A suc/i t/mi we Ziaue (/i * r; e) — > 
(/l' * r"; e') /or some hi , r" and e'. 

Furthermore, if A is suc/i £/ia£ — > 0' /or some 0' iften £/iere exists T" such that 0'; T" D> 
{h! * r"; e') : T < T' * r' fto/ds. 

Theorem |3. 18| is the particular case where A = t. 



Corollary 7.17 (Theorem 3.19) IfT> contains no name declaration and is empty, then there 



exists s' such that (h * r; e) — > s 
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Proof. [(Corollary)] In that particular case, h h : V implies that the heap cannot contain any n 
or c p , hence A can only be r or of the form C.mQ. 

Proof. [(Theorem)] We always use typing derivations where subsumption steps only occur at the 
positions described in Lemma [7. 2 [ Furthermore, it is sufficient to consider only cases where sub- 
sumption does not occur at the end: indeed, if it does occur, then we can add a similar subsumption 
step to the new judgement. The hypothesis in the theorem that 0; T t> (h* r; e) : T < V * r' 
holds is necessarily a result of T-State and therefore is equivalent to the two hypotheses h h : T 
and Y * r l> e : T <\V * r' . which we will sometimes refer to directly. 

We prove the theorem by induction on the structure of e with respect to contexts, and present 
the inductive case first: 



If e is of the form £[e\\ where ei is not a value and £ is not just [_] then Lemma 7.11 tells us that 
r * r t> e\ : U < T\ * r± appears in the typing derivation of T * r > e : T < V * r' for some U, r\ 
and IV From there we can apply T-State and derive 0; T > (h* r; e x ) : U < Ti * r%. This allows 

us to use the induction hypothesis and get A, 62, r" and h! such that (h * r; ei) — > (h' * r"; &2)- 

Then we straightforwardly have e — £[^2], either by applying R-Context if A is t or by 

replacing the context in the transition rule if it is something else. Now if A is such that — > 0' 
then the induction hypothesis^also gives us T" such that 0'; T" > (h' * r"; 62) ■ U < T 1 * T\ holds. 
From this we get, by reading T-State upwards, 0' h h' : T" and T" * r" > e% : U < Ti * n. We 
use Lemma 7.12| with the latter in order to obtain Y" * r" \> £[e-2\ :T <\T' * r' and conclude with 



T-State. 

The base cases are if e is of the form £[v] with £ elementary (i.e. not of the form £[£'] with 
£' 7^ [_]) and if it is not of the form £[ei] at all. We list them below. 

• If e is a value, there is nothing to prove. 

• e cannot be a variable. Indeed, 6h/i:f implies that dom(T) contains only object identifiers 
and channel endpoints. Therefore, T * r \> e : T <l V * r 1 cannot be a conclusion of T-Var 
or T-LinVar, thus e is not a variable. 

• e = v: e'. Then the expression reduces by R-Seq and the initial derivation is as follows: 

(1) — 

r * r > v : T' < Ti * r l"i * r > e' : T < T' * r' (b) 

—— (T-Seq) 

6 h h : T (a) r * r > v; e' : T < T' * r' 

— p (T-State) 

0; T > (h* r; v; e ) : T < T * r 

Furthermore, T' is not a link type. Therefore, (1) cannot be T-VarF or T-VarS and it 
is either T-Ref, T-Chan, T-Name, T-Label or T-Null, since these are the only rules 
for typing values. If it is T-Null, T-Label or T-Name, then r = T\\ if it is T-Ref or 



T-Chan, then T <: Tx and we can use Lemma 3.14 to get T * r t> e' : T < V * r' from (b) 



in both cases. We conclude from this using (a) and T-State. 

e = new CQ. Then the expression reduces by R-New and the initial reduction is as follows: 

(T-New) 

h h : F (a) r * r > new CQ : Csession < F * r 

(T-State) - 



0; T > (h * r; new CQ) : Csession < V * r 



Let S = Csession. From the hypothesis that V is well-typed, we have h class C {S; /; M}. 
This must come from T-Class, therefore we have Null / h C : S (b). 
We build the following derivation: 



(T-Hadd) 



T-Null, T-Swap, T-Seq 

(a) r, o : C'[Nut\ f]*o>f^Nut\: Null < T, o : C[Nufi f]*o 

,_,„ , ehh,{o = Clf = ^\]}:r,o:C[N^\f] (b) 
(T-Hide) 

h h, {o = C[f = nuli]} : T, o : S 



2 clearly there is no A such that we would have £[e\] — ► but not ei — >-, hence it is legitimate to use the 
induction hypothesis here. 
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then conclude 9; T, o : S > (h, {o = C[f = null]} * r; o) : S < T * r using T-Ref (it is not 
possible that r starts with o since o is fresh) and T-State. 

e = switch (u) {Z : e;}i e £. Then we have two cases. The slightly more complex one is if the 
initial derivation is as follows: 

i) is a label 



r * r > v : {v} < T * r T(r./) = S 

r * r > u : link / < T{r.f i-y (v : S)} * r v £ E (b) r * r > e„ : T < r" * r (c) 

r * r > switch (v) : e t }i eE :T<Y'*r 

(using T-Label, T-VarS, T-SwitchLink top to bottom). As usual we also have Q\- h:T 

(a) as the other premise of T-State (omitted for lack of space). The reason why the initial 
environment of judgement (c) is T is because it is obtained from the version of T with the 
type of r.f modified by modifying this type again, putting back S instead of the variant. 

(b) implies that the expression reduces by R-Switch. As regards type preservation, we 
can conclude 9;T t> {h*r; e v ) : T < V * r directly from (a), (c), and T-State. The 
other case is when the T-VarS step is absent and the following rule is T-SwiTCH instead 
of T-SwitchLink; the argument is the same. 

e = / «-> v. Then the initial derivation is as follows: 

r * r > v' : T' < Ti *r (b) TUr.f) = T (c) T is not a variant (d) 

(T-SwAP) 

r * r > / O v' : T < Ti{r./ h> T'} * r 

and we also have, as usual, 8 h h : V (a). The fact that Ti(r./) is defined implies that 
r(r./) is also defined, indeed the effect of typing v can only remove from the environment 
or create a variant type, so it can only decrease the set of valid field references. Thus h(r).f 
is defined as well, and the expression reduces by R-SWAP. Let v = h(r).f. From (a), (b), 



(c) and (d), we use Lemma 7.9 to get T" such that 9 h h{r.f M- v'} : T". We then notice 



that in each of the three cases of the lemma we have T" * r E> v : T < T±{r.f >->• T'} * r: 

1. If v is an object identifier or channel endpoint then V" = T\{r.f h-> T'},w : T. We use 
T-Ref or T-Chan. 

2. If u is not an object or channel and T is not a link type, then v is either null, an access 
point name or a label. We use T-Null, T-Name or T-Label. 

3. IfT= link/' then Tx(r.f) = (I : Si)i eE with v G £ and we have T" = r x {r./ ^ T'}{r./' 
SV,}. We use T-Label, T-VarS and T-SubEnv. 

Finally we conclude with T-State. 

e = return v. Then the expression reduces by R-Return. The initial derivation is as follows: 

(1) r*r./>^:T! <F 1 *r.f T^r.f) = C[F] F h C : S (b) 

(T-Return) 



r * r.f > return v : T < Tifr./ i-> 5} * r 

with also 6h/i:f (a). We distinguish cases depending on what rule (1) is: 

- If (1) is T-Null, T-Name or T-Label then T = T 1} and if it is T-Ref or T-Chan 
then r = Tx,v : T t . In both cases we have T(r.f) = T^r.f) and T x = T. From 



(a) and (b) we deduce h h : T{r.f H> S} using the closing lemma (Lemma 7.8). 
We then use T-Null, T-Name, T-Label, T-Chan or T-Ref, as appropriate, to get 
T{r.f H> S} * r > v : T\ < T\{r.f i-> 5} * r, and we conclude with T-State. 

- (1) cannot be T-VarS because T-Return forbids that T\ be of the form link /'. 

— If (1) is T-VarF, then T± = linkthis and T = link /. Furthermore, v is a label, 
F = (v : F') with F' not a variant, and T = r x {r./ ^ C[F']}. (b) then implies that S 
is of the form (I : Si)i^e with v £ E and F' h C : S^. Note that because F' is not a 
variant, S v must be a branch. Now, from that judgement and (a), we use the closing 
lemma to get 9 h h : T{r.f M> S v }. Let T" = T{r.f n- S v }. Since T only differs from 
Ti by the type of r.f, it is also the case of T" , and as (v : S v ) is a subtype of S, we have 
T"{r.f H> (u : S*!,)} <: Tifr./ i— > S}. From all this, we build the following derivation: 
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(T-Label) v is a label 

T" * r > v : M < T" * r S v branch 
(T-VarS) — 

T-SubEnv) — V — 

Bh h-.r{r.f ^ S v \ r" * r > v : T < T' * r 

T-State) — — 

6 ; r" > (h* r; v) : T < T' *r 

• e = spawn C.m(v). The initial derivation involves T-Spawn, and v is null. The premise that 
the method exists implies that the state can reduce by R-Spawn, which corresponds to a 
C.mQ transition. The new derivation is obtained replacing T-Spawn with T-Null. 

• e = f.m(v). The initial derivation is as follows, with m = rrij and j G /: 

, m „ . r * r > v : T' < Ti * r 
(T-Sub) 



r*r>v:T(<ri*r T^r.f) = {T t m,(T/) : Si} ieI (b) 

(T-Call) 

r *r > f.mj{v) : T < Ti{r./ t->- Sj} *r 

and we also have Bh/iiT (a). T is obtained from Tj as specified in T-Call, i.e. replacing 
linkthis with link / if necessary. Let S — {T, mj(T/) : Si}i^i. First note that Tj is a part of 
a method signature and that only a restricted set of types is allowed there: it cannot be of 
the form link /'. Furthermore, (1) cannot be T-VarF because of (b), thus T' is not linkthis 
either. Indeed, if T^r) were a variant, I\(r./) would not be defined. Therefore (1) is either 
T-Null, T-Label, T-Chan, T-Name or T-Ref and in all cases we have T(r.f) = T 1 (r.f). 
As it is a session type, it implies because of (a) that h(r).f exists and is either an object 
identifier, an access point name or a channel endpoint. We distinguish these three cases: 



h(r).f is an object identifier o. We use (a) and the opening lemma (Lemma 7.7 1 to 
get a field typing C[F] such that 8h/i: T{r.f h-> C[F}} and F h C : S. This last 
judgement implies, by definition, that F is not a variant; that, among others, method 
rrij appears in the declaration of class C; and that, if ej is its body and x its parameter, 
we have x : Tj, this : C[F] * this > e 3 : Tj < this : C[Fj] * this and Fj h C : S r The fact 
that the method is declared implies (h*r; e) — > (h*r.f; return ej{ v / x }); we now have 



to type this resulting state. For this, we apply the substitution lemma (Lemma 7.101 
to the typing judgement for ej, using Ti{r.f i— ► C[F}} as the T of the lemma and r.f 
as the r of the lemma. The first case of the lemma corresponds to (1) being T-Null, 
T-Label or T-Name; the second one corresponds to (1) being T-Ref or T-Chan. In 
both cases, the resulting judgement is: 

T{r.f ^ C[F}} * r.f > e,{ v / x } : Tj < T^r.f ^ C[Fj}} * r.f 

Indeed, the difference between T and Ti depends on (1) in the same way as the lemma's 
result. From this and Fj h C : Sj we can now apply T-Return and get: 

T{r.f i y C[F}} * r.f t> return e {"/ x } : T < Ti{r.f h-> Sj} * r 

where T is the same as in the initial derivation. We then conclude, using the heap 
typing that was provided by the opening lemma, with T-State. 

h(r).f is an access point name n. Then T(r.f) must come, in the derivation of O h h : T, 
from T-Name, which implies that n is declared, that rrij is either accept or request, 
and that Tj :> JS] where £ is either the declared type or its dual depending on which 
one rrij is. All this implies that the state does a n[c p ] transition where c is fresh and 

n[c p ] 

p depends, again, on rrij, and that — > 0,c p : S. The resulting state is typed using 
T" = T, C p : [E] and T-Chan. 

h(r).f is a channel endpoint c p . Then h h : V implies that cP £ dom(Q) and 
S :> J0(c p )]. Hence rrij is either send or receive. We distinguish the two cases. In the 
first case, the fact that S contains send implies that 0(c p ) is either of the form ! [Tj'] .£ 
with Tj <: T" or © : £ ; } ieB and then Tj = {v} and v e E. If v is not an object 
identifier then the state does a c p ! [u] transition. We can see that in both cases (send 
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and select) , 8 is able to follow that transition and evolves in such a way that 0' h h : V 
holds: the session type of c p is advanced and if v was a channel it is removed from the 
environment, which corresponds to the difference between T and V , thus it suffices to 
change the instance of T-Hempty at the root of the derivation leading to (a) to get 
this new typing. Then the new state is typed using T-Null and T-State. If v is an 
object identifier, then (1) is T-Ref and thus v £ dom(T), which implies (using (a)) 
that v is a root of h, so the state does a c p ! [h 1 v] transition. We use the splitting 



lemma (Lemma 7.4 1 to see that 8 is able to follow this transition and yields a 8' such 
that we have 8' h h f V :T'. We can then again conclude using T-Null and T- State. 
In the case where rrij is receive, the state can straightforwardly do a transition, which 
will be a receive on channel c p , however the transition label is not completely determined 
by the original state as we do not know what will be received. So we have to prove 
type preservation in all cases where the transition label A is such that 8 8' for 
some 8'. If A is of the form c p ? [v'], then this hypothesis tells us that 8(c p ) is either of 
the form ? [To] .S, and then v' must be a literal value of type To or a channel endpoint 
which gets added to the environment with a type smaller that Tq, or of the form 
: T^i} leE , and then v' £ E. In the first case we must have T <: Tj, thus the 
resulting expression, which is v' , can be typed using the appropriate literal value rule, 
or T-Chan, and subsumption. In the second one, Tj = linkthis so that T = link /; 
the resulting expression can be typed using T-Label and T-VarS. As for the new 
initial environment, it is obtained, as in the case of send, by replacing the instance of 
T-Hempty at the top of the derivation for (a) with one using 8' instead of 8, so that 
v' gets added to the initial environment if it is a channel and that the session type of 
r.f is correctly advanced, meaning, in the case of a branch, that it is advanced to the 
particular session corresponding to v', the variant type being reconstituted in the final 
environment by T-VarS. Finally, if A is of the form cP ? [h'], then we have 8' = 8 + 8" 



with 8" \- h! : o :Tj. where o is the only root of h! . The merging lemma (Lemma 7.5 1 
gives us a typing for the new heap and, as in the other cases, advancing the session 
type of c p yields a session type change in r.f, corresponding to the difference between 
T and T'. We conclude using T-Ref and T-State.D 

The following two lemmas will allow us to deduce from this theorem the proof of subject 
reduction for configurations. 



Lemma 7.18 //9hs and s = s' then 8 h s' . 

Proof. By induction on the derivation of s = s' . 

Lemma 7.19 If s — > s' , then either: 

1. s=(vc)((h*r; e)\\s"), 
s' = (wj)((/i'*r'; e') || a") 
and (h * r; e) — — > {h! * r'; e'), or 



2. s = (yc) {(hi * n; e x ) \\{h 2 * r 2 ; e 2 ) || s"), 

s' = (vc)(vd) ((hi * n; e[) \\(h 2 * r 2 ; e' 2 ) || s"), 

(h\*ri; ei) n ^—^ (hi*T\\ e' x ) and (h 2 * r 2 ; e 2 ) (h 2 * r 2 ; e' 2 ), or 

3. s = (vc) ((hi * n; ex) || (h 2 * r 2 ; e 2 ) \\ s"), 
s' = (vc) ((hi * n; ei) || (h 2 * r 2 ; e' 2 ) \\ s"), 

c p ! [v] c p ?M 

(hi*ri; ei) — (fii*ri; e[) and (h 2 *r 2 ; e 2 ) — > (h 2 *r 2 ; e' 2 ), or 

4. s = (vc) ((hi * ri; ei) \\(h 2 * r 2 ; e 2 ) \\ s"), 
^^^((h'^ri; e[)\\(h' 2 *r 2 ; e' 2 )\\s"), 

c p \ [h'] c p ?[ v {h')] 

(hi*ri; ei) — > (hj_*ri\ ei) and (h 2 * r 2 ; e 2 ) — > (h' 2 *r 2 ; e' 2 ) 
with h' = hi J, o, h'i = hi f o, and h' 2 = h 2 + <p(h'), or 
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5. s=(vc)((h*r; e)\\s"), 

s' = (vc) {{h * r- e') || (o = C[f = nuli] * o; e"{ nu "/*}) || s") 

where C.fields = f , o is fresh and m(x) {e"} G C . 



and (h * r; e) ^ — P (/i * r; e' 



Proof. This is nothing more than a reformulation of the reduction rules in terms of labelled 
transitions: the derivation for s — > s' can contain any number of instances of R-Par, R-Str or 
R-NewChan but must have one of the other rules at the top. It is straightforward to see that 
depending on that top rule we are in one of the five cases listed: (1) for any of the single-thread 
rules in Figure [F] (2) for R-Ini t, (3) for R-ComBase (4) fo r R-ComObj, and (5) fo r R-Spawn. 

We can now prove Theorem 7.13 Proof. [(Theorem 7.13 l] Because of Lemma 7.18 we only need 
to look at the different cases described in Lemma [7.191 

In cases (1) and (5), the initial derivation is as follows: 



(T-Thread) 



9i;ri> (h*r; e) : T < T' * r" 
01 h (h * r; e) 



7.13 



(T-Par) 
(T-NewChan) 

gives us 8i; r 



02 I- . 



©l +©2 I- (h*r; e) 



T < V 



from there the final 



In case (1), Theorem 
derivation is the same. 

In case (5), the theorem gives us the same result, but the final derivation is more complicated 
as there is one more parallel component. The C.mQ transition tells us that e must be of the form 
£ [spawn C.m(v)]. From Lemma 7.11 this implies that the subexpression spawn C.m(v) is typable, 
which must be a consequence of T-Spawn, implying that m appears in the initial session type S 
of C with a Null argument type. As, by hypothesis, the declaration of class C is well-typed, this 
implies (from T-Cl ass) x : Null, this : C[Null f] * this D> e" : T < this : C[F] * this. We apply the 
substitution lemma (7.101 to this judgement to replace this with o and x with null, and we build 
the heap typing h o = C[f = nuti] : o : C[Null f] from T-Hempty and T-Hadd. This gives a 
typing for the new thread, with an empty 0, using T-State and T-Thread and we can conclude 
with T-Par. 

In cases (2), (3), and (4), the initial derivation is: 



©i;ri > (hi * ri; ei) : Tj < 1^ * ; 



2 ;r 2 > (h 2 * r 2 ; e 2 ) : T 2 < T' 2 * r' 2 



(T-Par) 



©i h (hi *n; ei) ©2 I- (h 2 * r 2 ; 

, m „ . ©l + ©2 I- (hi *n; ei) || (h 2 *r2', e 2 ) 
(T-Par) 



e 2 ) 



ehs" 



(T-NewChan) 



©i + ©2 + © h (hi * n; ei) || (h 2 * r 2 ; e 2 ) \\ s" 



Furthermore, we can deduce from the transition labels that the expressions in the two topmost 
premises are of the form £i[fi.mi(vi)] and £2[f2-m2(v2)] with h\(ri).fi and ft-2(? , 2)-/2 being, in 
case (2), n, and in cases (3) and (4), respectively c p and <? '. These two topmost premises must 
come from T-State, which implies 0i h h\ : Ti and 2 h h 2 : r 2 , from which we deduce, in case 
(2), that n is a declared access point name and i n cases (3) and (4) that [0i(c p )J <: ri(ri./i) 
and |02(c p )] <: r 2 (r2./2)- We use Theorem 7.13 on these two topmost premises and distinguish 
cases. 

In case (2), Q\ and 02 make transitions which introduce two dual types for d + and d~ , which 
are fresh so that the disjoint unions are still possible, and we just need to add an additional step 
of T-NewChan before the last one. 

In cases (3) and (4), we first remark that because T-NewChan in the derivation leads to an 
empty environment, c must be one of the chan nels i n (yc) and we must have 0i(c p ) = £ and 
02 (c p ) = £ for some S. Then we use Lemma 



7.11 



to get a typing judgement for the method 
call subexpression on the sending side (thread 1). This judgement has Ti as an initial typing 
environment and comes from T-Call; as we have E <: r 1 (r 1 ./ 1 ), this implies that E is either of 
the form ! [T] .E' with v (in case (3)) or o (in case (4)) of type T, or (only in case (3)) of the form 
© {I : E;} ;eB with v E E. The simplest case is (3): then this typing information, together with 
the duality of the two endpoint types, shows that ©2 follows the transition with the new type of 
cF still dual to the new type of c p . In the case where v is a channel endpoint, its typing goes from 
0i to 2 but stays the same, so that it is unchanged in the sum environment yielded by T-Par. 
Thus we can still apply T-NewChan. 
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Case (4) is similar but, additionally, a renaming function is applied to the transmitted heap. 
We use Lemma [7. 6 1 to see that the type of its only root, which is all we need, stays the same, so 
that again Q 2 can follow the transition. We also have that a whole part of the channel environment 
can go from Oi to O2 but the effect is the same as with just one channel: it does not affect the 
sum environment resulting from T-Par. So again we can still apply T-NewChan.D 

7.3 Type safety 

We now have the following safety result, ensuring not only race-freedom (no two sends or receives 
in parallel on the same endpoint of a channel) but also that the communication is successful. 

Theorem 7.20 (No Communication Errors) Let 

s = [vc)(s' II (h * r; £ [r.f.m(v)]) \ \ (ti * r'; £[r' . f .m' (v 1 )])) 
and suppose that h s holds. Ifh(r).f — cP and h'(r').f = c q then: 

1. q=p, 

2. channel c does not occur in s' , and 

3. there exists s" such that s — > s" . 

As the statement is true in particular when s' is empty, it implies that communication between 
the two threads is possible. Proof. This is an essentially straightforward consequence of h s. 



The typing derivation is similar to the one shown for cases 2/3/4 in Theorem 7.13 above; the 
two top premises must be consequences of T-State and the heap typing necessary to apply this 
rule implies, respectively, Ti(r.f) :> [Oi(c p )J and T 2 (r' .f) :> |02(c 9 )]. Because of the disjoint 
unions in T-Par, c p <E dom(®i) and c q 6 dom(®2) immediately imply (1) and (2); (3) is then 
a consequence of the duality constraint imposed by T-NewChan: looking at the translations of 
dual channel types, and because the method call subexpressions must be typed by T-Call, if m 
is send then m' must be receive and vice-versa. 



This theorem, together with the progress aspect of Theorem 7.16 restricts the set of blocked 
configurations to the following: if h s and s -/—>, then all parallel components in s are either 
terminated (reduced to values), unmatched accepts or requests, or method calls on pairwise distinct 
channels — this last case corresponding to a deadlock. 

7.4 Conformance 



We now have the technical material necessary to prove Theorem 3.3 1| (conformance). Note that 



we do not formally extend this result to the distributed setting, as stating a similar property in 
that case would require more complex definitions describing, among other things, how call traces 
are moved around between threads; however we can see informally that, because objects keep their 
content and session type when transmitted, all necessary information is kept such that we still 
have a conformance property. 

Proof. We first prove, by strong induction on n, a slightly different result, namely the following: 
for each i there is I\ such that P* > (hi * r^; e,) : T < T' * r' and tr% is consistent with IV 

We suppose that this property is true for any reduction sequence of length n or less whose 
initial state satisfies the hypotheses and prove that it is true also for length n + 1. The base case 
71 = 1 is trivial. 

If the nth reduction step (h n * r„; e n ) — > {hn+i * r n+i! e-n+l) does not originate from R- 
Return, we use the induction hypothesis on the beginning of the sequence; we refer to the cases 



in the proof of Theorem 7.16 to show that the T„ + i it allows to construct from Y n indeed is 
consistent with ir„ +1 . Because we are only interested in and not P, in most cases we can 

use Lemmas |7.11| and |7.12| to ignore any context £ and proceed as if the reduction is exactly an 
instance of its original rule. 

If the rule is R-Seq, R-Switch or R-Swap then tr n+1 = tr n . 

If the rule is R-Seq or R-Switch then the proof of Theorem |7. 16| shows that we can choose 
r„ + i = r„, so there is nothing more to prove. 
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If the rule is R-Swap then the proof of Theorem 7.16 indicates that r n+ i (called T" in subject 



reduction) can be defined using Lemma 7.9 from the V" (called I\ in subject reduction) obtained 
after typing v' , the value that gets swapped into the field. First of all note that most objects, 
notably all those which are not v' and not in a field of r, have the same type and position in the 
heap in r n+ i as they have in T. For all them the result is straightforward: we only concentrate 
on those objects that move or change type. Depending on the nature of T and T' (object, link, 
or base type), there may be one or two of them. Recall that neither type can be linkthis as else 
the expression would not be typable. We distinguish cases separately for T and T", knowing that 
any combination is possible (except both linking to the same field). Cases for T': 

• If T' is an object type (thus v' is an object name o'), then T n+ i(r.f) — T n (o') (the rule used 
for v' is T-Ref). We also have tr n+ i(h n +i(r.f)) — tr n+ i(o') — tr n (o'), so tr n+ i is indeed 
consistent with r n+1 with respect to reference r.f. 

• If T is link /', the rule used for v' is T-VarS, and T n+1 (r.f) = (v 1 : S v >). We have 
r n +i (?'•/) = link /' and h n +\(r.f) = v' , hence the actual session type of r.f in h n+ i 
according to r n+ i is S v >. Thus consistency is preserved for r.f. 



Cases for T (corresponding respectively to cases 1 and 3 of Lemma 7.9) 



If T is an object type (thus h n (r.f) is an object name o), then r, l+ i contains a new entry 
for o, with type T n (r.f). Consistency for this new entry comes from consistency for r.f at 
the previous step. 

If T is link /", then T n (r.f) = (I : Si)i^e and h n (r.f) = Iq is in E. Thus the actual session 



type of r.f" in h n according to T n is Si . Lemma 7.9 also gives us T n+ i(r.f) — 5; , hence 



the actual session type of r.f" has not changed, and consistency is preserved. 



If the rule is R-New then the proof of Theorem 7.16 shows that a suitable r n+1 is of the form 
r„,o : C.session where o is the fresh object name introduced by the reduction. Definition |3.26| 
states that tr n+ \ extends tr n by assigning an empty call trace to o; clearly tr n+ i is consistent 

with r n+ i. 



If the rule is R-Call then the proof of Theorem 7.16 shows that a suitable r n+1 is T n with 
the type of r.f replaced by a type which is not a session. So there is no consistency requirement in 
r„ + i for r.f. and every other reference is given the same call trace by tr n+ i as by tr n . Therefore 
tr n+ \ is consistent with r n+ i. 

Now if the nth step originates from R-Return, we reason slightly differently. We know by 
hypothesis that r\ is a prefix of r„ +1 . Furthermore, since the nth step is R-Return, r n is of 
the form r n+ i.f. Reduction rules can only alter the current object by removing or adding one 
single field reference at once, therefore there must be a previous reduction step in the sequence, 
say the ith, that last went from r n+ i to r n+ i.f. That is, we chose i such that r n+ \.f is a prefix 
of all rj for j between i + 1 and n and that ri — r n +%. That step must originate from R-Call 
as it is the only rule which adds a field specification to the current object. Thus, it is of the form 
(hi * r n+ i; £(f.m(v'))) — > (hi + i * r n+ \.f\ ^(return e)), where e is the method body of m with 
the parameter substituted. Then it is straightforward to see that the whole reduction sequence 
from i + 1 to n consists of reductions of e inside the context £ (return [_]). 

We first use the induction hypothesis on the first part of the reduction (1 to i) so as to get 
judgments up to t> (hi * r n+1 ; £ (f .m(v'))) : T <\ V * r' . We then use Lemma 7.11| to get Ti \> 



(hi * r n+ i] f.m(v')) : T' < T" * r" and note that this judgment must come from T-Call, which 
implies that r" — r n+ i, that Ti(r n+ i.f) is of the form {T" m(. . .) : S, . . .} and that r"(r Jl+ i./) = S. 
Furthermore, T' is either a base type if S is a branch or link / if it is a variant. We know that tri 

is consistent with I\, therefore we have class(o). session — >* {T' m(. . .) : S, . . .} — > S. 

We now use the induction hypothesis again on the reduction sequence from i to n for this 
particular call subexpression, recalling that i has been defined such that the hypothesis on the 
current object is indeed satisfied by this sequence. We can also use Lemma |7.12| at each step in 
order to lift the judgements thus obtained to the whole expression. To summarise, this means that 
for any j between i + 1 and n we have: ej = £( return e'f for some e'j, Tj > (hj * r^; return e'f : 
T' < r" * r n+ i and Tj > (hj * rj; ej) : T < V * r' , and that trj is consistent with Tj. 
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W(C) = -4c(C.session, C.fields, 0) 

if for every req F ens F' for T' m(T x) {e} e C 

F' ^ (_> and B C (e, F,x:T) = (T", F' , _) 

A C (S, F, A) = A if (F.S 1 ) 6 A 

A;(^.S, A) = A C (S{» X - S / X }, F, AU{(F # XS)}) 

^c({7i m<(f7j) : Si}i<i<n. *\ An) = A n 
where for i = 1 to n 

let (TV, F!, _) = o (e», F, x t : t/;) where m^) {a} e C 
if TV <: Ti then let Aj = A c (Si, Ft, Ai_i) 
else if TV is an enumeration i? and Tj = linkthis 

then let Aj = Ac (Si, (I : F!)i eB , Ai_i) 
else if TV = linkthis and Ti is an enumeration i? and fV = (i : Fi) ieE i and E' <Z E 
then let A 4 = A^Si, V ieB ' Ai-i) 
-4c((i : 5i); SB , (Z : ivies', An) = A n 

where E' = {h .../„} C E and for i = 1 to n, Aj = ^(S^, -F;., Aj_i) 

Combining variants 

{Ti fi} ieI V {T/ fi} ieI = {(Ti V T/) f t } ieI 
(I : F t ) lEl V (i : F() le j = (I : F(') lEIUJ 

where F ; " = F t V J 1 / if / 6 / n J, F ; if I g J, F{ if I g I 



Figure 27: Typechecking: algorithms W and A. 



For the last reduction step, R- Return, the proof of Theorem 1 7 . 1 6| tells us that we can choose 
a r n+ i which is identical to r„ except for the type of r n+ i.f, and as the call trace for other 
references is not modified, consistency is preserved for them. For r n+ \.f we have to look back at 
the initial subexpression on step i. First note that R-Swap can only act on a field of the current 
object, therefore since r n+ i.f is a prefix of the current object during the whole subsequence, its 
content cannot change and is the same object o throughout. Similarly, there is no other R-Call 
or R-Return acting on that particular object, hence tr n (o) = tr i+1 (o) = tri(o)m. We saw 
above that this call trace leads the initial session of o to S. Then the judgement for the final 
subexpression, at step n + 1, is of the form r„ + i > (h n+ i * r n+ i; v) : T' < T" * r n+ i. There are 
two cases, as in the proof of Theorem 7.16 If T' is a base type then S is a branch and it is possible 
to decide that r„ + i(r n+ i./) is equal to 5*. In that case the call trace either does not change or 
has a label appended, but as S is a branch it can do a transition to itself with any label, therefore 
tr n +i(o) is consistent with r„ + i(r Il+ i./) in both cases. If T' is link /, then v is a label, S is a 
variant (I : Si)i^e and r n _|_i(r„+i./) can be chosen equal to S v . We have ir n +i(o) = tr n (o)v and 
S — % S v , so consistency is preserved. 



This completes the inductive proof that for every step i in the reduction sequence there is Fj 
such that Ti > (hi * rf, e,) : T < V * r' and tr, is consistent with r,-. This fact obviously implies 
that tri is valid for all the objects which have a session type in T^; we now argue that it is also the 
case for the other objects, namely those which either are not at all in 1^ or do not have a session 
type. We know by hypothesis that it is the case for try and show by a very simple induction that 
it cannot change from i to i + 1. The ith step can only change the call trace for an object o if 
it originates from R-Call or R-Return concerning that object. R-Call can only occur if the 
reducible part of the expression is indeed a method call on a field which contains o, and that is 
only typable if Ti contains a session type for that field which is a branch containing the method, 
and thus allows the appropriate transition: therefore validity of the call trace for o is preserved 
in that case. R- Return on the other hand can only occur if the reducible part of the expression 
is a return and if the current object is (the address of) o, and we saw that in that case the r^+i 
constructed in our proof contains a session type for o, so this case is covered by the consistency 
result. 
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Bo(null, F, V) = (Null, F, V) 
B c (n, F, V) = ([(n.protocol)], F, V) 

B c {x, F,y:T) = (T, F, V) if X = y, where V = if T is linear or y : T otherwise 
B c (f <-> e, F, V) = (U, F", V) 

where (T, F', V") = Bc(e, F, V) and F'(/) is not a variant and 

if T = linkthis then F' = (I : F l ) l&E and U = (V ieB F)(/) and F" = (V iei5 F){/ ^ F} 
else (7 = F'(/) and F" = F'{f ^ T} 
B c (l, F, V) = (linkthis, (I : F>, V) 
B c (new C"(), F, V) = (C'.session, F, V) 
B c U-m 3 {e), F, V) = (T, F", V") 

where (T", F', V") = Z3 c (e, F V) and 

if T' = linkthis then F' = (I : F{)i &E and (V ieB Fj)(/) = {T, m t (T/) : Si} ieI and 36/ 
and Tj is an enumeration F' and E C E' and F" = (\/ lEE F;){/ t-» S<} and 
T = link / if Tj = linkthis, T = Tj otherwise 
else F'(/) = {Tt m^T/) : 5i} lS/ and j E l and T" <: Tj and 

F" = F'{/ h-> Sj} and T = link / if Tj = linkthis, T = F,- otherwise 

Bo(m(e), F, V) = (T', F'", V) 

where (T, F', V') = B c (e, F, V) and req F" ens F" for T' m(T" x) {e} e C and 
if T = linkthis then F' = (I : F{)i^ E and T" is an enumeration E' and 

F C F' and VjefiF <: F" 
else T <: T" and F' <: F" 
B c (switch (e) {/ : ei } leE , F, V) = (T, V ie£ F/', V") 
where ([/, F', V') = S c (e, F, V) and 

i£U = E' then F' C F and VZ e F'.(T, F/', V") = B c {e u F', V") 
else if U = linkthis then F' = (m : G m ) m £E' an( i E' C E and 

Vi e F'.(T, F/', y") = B c ( ei , V meB ' Gm, V) 
else if U = link / then 

F'(f) = (I : Si) leB , and F' C F and V« e F'.(T, F/', V") = B c {e u F'{f h> V") 
B c (while (e) {e'}, F, V) = (Null, F", V) 
where ([/, F', V") = B c (e, F, V) and 

if U = E' then E' C {True, False} and Bc(e', F', V") = (Null, F, y) and F" = F' 
else if (7 = linkthis then F' = (I : F;)igB and F C {True, False} and 

Bo(e', VigB F> V") = (Null, F, V) and F" = V leB F, 
else if (7 = link / then F'(/) = (True : Sj rue , False : Spaise) an< i 

B C (e', F'{f k> 5 TrU e}, V) = (Null, F, V) and F" = F'{/ h> 5 False } 
B c (e; e', F, V) = B (e', F", V') 

where (T, F', V") = S C (e, F, V) and T ^ link _ and 
if T = linkthis then F' = {I : F,}; g b and F" = V; eB F 
else F" = F' 
Bc(spawn C'.m(e), F, V) = (Null, F', V") 

where (Null, F', V) = B c (e, F, VQ and Null m(Null) 6 C'.session 



Figure 28: Typechecking: algorithm B. 



8 Type Checking Algorithm 

This section introduces a type checking algorithm, sound and complete with respect to the type 
system in Section [6] and describes a prototype implementation of a programming language based 
on the ideas of the paper. 



8.1 The Algorithm 

Figures [27] and [28] define a type checking algorithm for the distributed language, including the 
sequential extensions from Section [4] The algorithm is applied to each component of a distributed 
system, and in order to ensure type safety of the complete system there must be some separate 
mechanism to check that each access point n is given the same type everywhere. A program is 
type checked by calling algorithm W on each class definition and checking that no call generates 



an error. The definition of algorithm W follows the typing rule T-Class in Figure 14 It calls 
algorithm A to check the relation F h C : S and algorithm B to type check the bodies of the 
methods that have req/ens annotations. Algorithm A also calls algorithm B to typecheck the 
bodies of the methods that appear in the session type. 
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class C { 1 
session { linkthis m(int): < FALSE: SCf, TRUE: SCt ) } 2 
where SCf = . . . , SCt = . . . 3 

4 

} 5 

6 

class D { 7 
session { linkthis a(int): ( FALSE: SDf, TRUE: SDt ), 8 
linkthis b(int): ( FALSE: SDf, TRUE: SDt }, 9 
{ FALSE, TRUE } c(int): SD1 , 10 
{ FALSE, TRUE, UNKNOWN } d(int): SD2 } 11 
where SDf = . . . , SDt = . . . , SD1 = . . . , SD2 = . . . 12 

13 

f ; 14 

15 

a ( x ) { // Not allowed , because return type is link f 16 
f ^ new C ( ) ; 17 
f.m(x); } 18 

19 

aa(x) { // Allowed , because body type is linkthis 20 
f <-> new C( ) ; 21 
switch (f.m(x)) { 22 
case FALSE: FALSE; 23 
case TRUE: TRUE; } } 24 

25 

b( x ) { // Allowed , by creating a uniform variant 26 
even(x); } 27 

28 

bb(x) { // Allowed , because body type is linkthis 29 
switch (even(x)) { 30 
case FALSE: FALSE; 31 
case TRUE: TRUE; } } 32 

33 

c ( x ) { // Allowed , by taking a join of field typings 34 
f o new C ( ) ; 35 
switch (f.m(x)) { 36 
case FALSE: FALSE; 37 
case TRUE: TRUE; } } 38 

39 

cc(x) { // Allowed , by taking a join of equal field typings 40 
switch (even(x)) { 41 
case FALSE: FALSE; 42 
case TRUE: TRUE; } } 43 

44 

d( x ) { // Allowed , because of subtyping between enumerations 45 
even(x);} 46 
} 47 



Figure 29: Example for type checking. 



In both A and B there are several "if" and "where" clauses; they should be interpreted as 
conditions which, if not satisfied, cause termination with a typing error. 

Because of the coinductive definition of F h C : S, algorithm A uses a set A of assumed 
relationships between field typings F and session types S. If there is no error then the algorithm 
returns A, but at the top level we are only interested in success or failure, not in the returned 
value. 

Algorithm B checks the typing judgement for expressions, defined in Figure [9j specialized to 



the top-level form this : C[F], V * this > e : T < this : C[F'],V' * this as explained in Section 3.4.1 
The definition of B follows the typing rules (Figure |9| except for one point: T-VarF means that 
the rules are not syntax-directed, as any expression with type E can also be given type linkthis. 
For this reason, clause I of B produces type linkthis and a variant field typing with the single 
label I. More general variant field typings are produced when typing switch expressions, as the 
V operator is used to combine the field typings arising from the branches. This is the typical 
situation when typing the body of a method whose return type is linkthis: the body contains a 
switch whose branches return different labels with different associated field typings. 
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It is possible, however, that giving type linkthis to I is incorrect. It might turn out that the 
expression needs to have an enumerated type E, for example in order to be passed as a method 
parameter or returned as a method result of type E. An expression that has been inappropiately 
typed with linkthis can, in general, be associated with any variant field typing, for example if it 
contains a switch whose branches yield different field typings. In this case, the algorithm uses V to 
combine the branches of the variant field typing into a single field typing; the join is always over all 
of the labels in the variant. This happens in several places in algorithm £>, indicated by conditions 
of the form "if T = linkthis", and in the final "else" branch of the third clause of algorithm A. 

The algorithm for checking subtyping is not described here but is similar to the one defined for 
channel session types in [31]. We write SV S' for the least upper bound of S and S' with respect to 
subtyping. It is defined by taking the intersection of sets of methods and the least upper bound of 
their continuations. Details of a similar definition (greatest lower bound of channel session types) 
can be found in |44j . 

The type checking algorithm is modular in the sense that to check class C we only need to 
know the session types of other classes, not their method definitions. 

We have not yet investigated type inference, but there are two ways in which it might be 
beneficial. One would be to infer the req/ens annotations. The other would be to support some 
form of polymorphism over field typings, along the lines that if method m does not use field / 
then it should be callable independently of the type of /. This might reduce the need to type 
check the definition of m every time it occurs in the session type. 



8.2 Examples of Type Checking 

Figure [29] defines classes C and D. In class C, only the outer layer of the session type is of interest; 
the example uses an object of class C but does not need the definition of method m. Class D, as 
well as the outer layer of the session type, contains a field f and one or two candidate definitions 
for each of the methods a, b, c and d. The definitions of a and aa are alternatives for the method 
a specified in the session type, and so on. 

The definition of a is not typable because the type of the returned expression is link /. Allowing 
this would let the caller of a have access to field f. Instead, the result of f .m(x) must be analyzed 
with a switch, as in the definition of aa, which is typable. The linkthis type required by the 
signature of a is introduced by the enumeration labels FALSE and TRUE in the branches of the 
switch. A compiler could insert switches of this kind automatically, allowing the definition of a 
as syntactic sugar. 

The remaining method definitions are all typable and illustrate different features of the type 
system and the algorithm. In the definition of b, the method even is supposed to be the obvious 
function for testing parity of an integer, returning TRUE or FALSE. This definition is typable 
even though the body of b does not introduce a linkthis type, because algorithm A constructs a 
variant field typing over {TRUE, FALSE} in which both options are the same. This is seen in the 
first else clause of A. The definition of bb achieves the same effect by using the labels FALSE and 
TRUE to introduce the type linkthis. Each label corresponds to a partial variant field typing, 
and checking the switch combines them by means of the V operator. Because the field f is not 
involved in the method body, the field typing is the same in both options of the variant. 

Method c has the same definition as a, but this time the signature in the session type specifies 
a simple enumeration as the return type. This is allowed, by using the V operator to construct 
the join of the field typings, in the second else clause of A. This means that when the algorithm 
proceeds to type check method definitions in the session type SD1, the type of f is taken to be the 
join of SCf and SCt. Whether or not this loss of information causes a problem will depend on the 
particular definitions of those types, which we have not shown. Method cc is handled in the same 
way, but this time there is no loss of information because the types being joined are identical; this 
in turn is because f is not involved in the method body. 

Finally, method d illustrates straightforward subtyping between enumerations, defined as set 
inclusion. 
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8.3 Correctness of the Algorithm 

The following sequence of results outlines the proof of soundness and completeness of the algorithm. 
The detailed proofs are routine and are omitted. 

Theorem 8.1 Algorithm A always terminates, either with an error (and then the function A is 
undefined) or with a result. 

Proof. Similar to proofs about algorithms for coinductively-defined subtyping relations |53l Chap- 
ter 16]. 

Lemma 8.2 // this : C[F], V * this > e : linkthis < this : C[F'], V' * this then for some E and 
{Fi} l€E , F' = (I : Fi) ieE and this : C[F], V * this t> e : E <i this : C[\J l&E Fy], V' * this. 

Proof. By induction on the typing derivation. 

Lemma 8.3 IfB c {e, F, V) = (T,F',V) then this : C[F],V * this > e : T < this : C[F% V * this. 
Proof. By induction on the structure of e. 

Lemma 8.4 //this : C[F],V* this > e : T < this : C[F], V * this andB c (e, F, V) = (T',F",V") 
then V" <: V and either 

1. T <: T and F" <: F' , or 

2. T = linkthis, T is an enumeration E, F' = (I : Fi) ieE ,, E C E' and V7 G £7. F" <: Fj, or 
5. T is an enumeration E, V = linkthis, F" = (I : Fi) leE ', E' C E and V/ G £". F t <: F' . 

Proof. By induction on the typing derivation. 
Theorem 8.5 If F h C : S then A C (S, F, 0) is defined. 

Proof. Consider the execution of Ac(S, F, 0). It terminates and has various calls of the form 
Ac(S', F' , A), including the top-level call. We prove the following statement, by induction on 
the number of recursive calls in the execution of Ac(S', F', A): if A C • h C : • and F' h C : S' 
then ^ C (S", i 7 ", A) is defined and A C {S' , F', A) C • h C : •. 

Lemma 8.6 If A C (S, F, A) is de/ned fen /or any A', _4 C (S, F, A U A') = ^4 C (5, F, A) U A'. 



Proof. Similar to the proof of Theorem |8.5[ by induction on the recursive calls within a given 
top-level call. 

Lemma 8.7 Suppose Ac{^X.Sq, Fq, 0) is defined and (Fq, fj,X.So) A. Then for all S and F, 
ifAc(S, F, A U {(Fq, [aX.Sq)}) is defined then Ac{S, F, A) is defined. 



Proof. Similar to the proof of Theorem |8.5[ by induction on the recursive calls within a given 
top-level call. 

Lemma 8.8 If A C {^X.S, F, 0) is defined then A C (S{^ X - S / x }, F, 0) is defined. 

Proof. By the definition of .A, Ac(nX.S, F, 0) = A C {S{^ X - S / x}, F, {(F, fiX.S)}), which is there- 
fore defined. By Lemma |8j] AciS^^/x}, F, 0) is defined. 



Corollary 8.9 If A C (S, F, 0) is defined then Ac (unfold (S), F, 0) is defined. 
Theorem 8.10 If A C {S, F, 0) is defined then F\~C : S. 

Proof. By Corollary |8.9| and the fact that F h C : S is defined in terms of the unfolded structure 
of session types, it is sufficient to consider the case in which S is guarded. 

Similarly to the proof of Theorem 8.5 consider the recursive calls in the execution of Ac (So, Fq, 0). 
We show that the following relation is a C-consistency relation: 

K = {(F, S) I A C (S, F', A) is called for some A and F' with F <: F'}. 

This is easily checked, using the three cases of Lemma [8T] to correspond to the three cases in the 
third clause of the definition of A. 
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8.4 Implementation 



We have used the Polyglot [51] system to implement the ideas of this paper as a prototype 
extension of Java 1.4 (extended with enum declarations), which we call Bica. The compiler 
accepts conventional Java code, possibly including ©session annotations in classes and in method 



parameters, as well as @req and (§ens annotations for recursive methods (cf. Section 4.2 1. All we 
do is extended type checking; there is no need to touch the back-end of the compiler. 

To keep in line with the expectations of Java programmers, annotations follow the first style 
in Figure [l] page [3] Also, the type system is nominal (cf. Section 4.4 1; label sets (cf. Figure |5| are 



explicitly introduced via Java 1.5 enum declarations. The ideas presented in this paper, addressing 
a subset of the Java language, are extended towards the whole language. In particular: 



The while loop technique described in Section 4.1 is extended to handle for and do— while 

loops. 

The same idea is used to type the various goto instructions present in Java: exceptions, 
break, continue and return, labelled versions included. 

All control flow instructions (including if— then, not discussed in the paper) can be used 
with conventional or with session-related boolean/enum values. 

Classes not featuring a ©session annotation are considered shared rather than linear. Their 



objects are treated very much like the null value (cf. Section 4.3). We do not allow a shared 
class to contain a linear field, even though it is perfectly acceptable for a method of a shared 
class to have a linear parameter. 

The same technique used for "top-level" classes is used for inner, nested, local (defined within 
methods) and anonymous classes. 

In order to mention overloaded methods in ©session annotations, alias names for these 
methods are introduced via extra annotations. 

Static fields are always shared. 



Class inheritance (cf. Section 4.4 1 is supported; interface or multiple inheritance is not. enum 



inheritance (contravariant subtyping) is supported via annotations. 
• The distributed part of the language is not implemented at the time of this writing. 
A prototype implementation is available from http://gloss.di.fc.ul.pt/bica/. 



9 Related Work 

Previous work on session types for object-oriented languages. Two lines of work, by 
Dezani-Ciancaglini, Yoshida et al. [ |13l 123] ; |22l I23| ] and by Hu [3S], have already been described 
in Section [T] We have explained that the distinctive feature of our work is that we can store a 
channel in a field of an object and allow several methods to use it. We are also able to interleave 
sessions on different channels. 

|38| have also extended SJ to support event-driven programming, with a session type discipline 
to ensure safe event handling and progress. We have not considered event-driven programming in 
our setting. 

Campos and Vasconcelos |lll H"2"] developed MOOL, a simple class-based object-oriented lan- 
guage, to study object usage and access. The novelties are that class usage types are attached 
to class definitions, and the communication mechanism is based on method call instead of being 
channel-based. The latter feature is the main difference with respect to our work. 
Non-uniform concurrent objects / active objects. Another related line of research, started 
by [5U], aimed at describing the behaviour of non-uniform active objects in concurrent systems, 
whose behaviour (including the set of available methods) may change dynamically. He defined 
subtyping for active objects, but did not formally define a language semantics or a type system. 
The topic has been continued, in the context of process calculi, by several authors |17j : |47| : 
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|48j : |57 [ [56 ] [55]: |9j[T0]J. [9] is the most relevant work; it uses an approach based on spatial types 
to give very fine-grained control of resources, and |45| has implemented a Java prototype based 
on this idea. [19 define a concurrent Java-like language incorporating inheritance and subtyping 
and equipped with a type-and-effect system, in which method availability is made dependent on 
the state of objects. 

The distinctive feature of our approach to non-uniform objects, in comparison with all of the 
above work, is that we allow an object's abstract state to depend on the result of a method call. 
This gives a very nice integration with the branching structure of channel session types, and with 
subtyping. 

Specifically related to the notion of subtyping between session types, the work of [58 is worth 
mentioning. He proposes a type-based approach to ensure that both component objects and 
their clients have compatible protocols. The typing discipline specifies not only how to use the 
component's methods, but also the notifications it sends to its clients. Rossie calls this enhanced 
specification a Logical Observable Entity (LOE) , which is a finite-state machine equipped with a 
subtyping notion. An LOE is a high-level description of an object, specifying which transitions 
(method executions) change its state, providing for each state both the available methods and 
notifications to be sent to the clients. LOEs support behavioural subtyping, in its afferent aspects 
(how clients may affect the LOE) — a subtype must allow at least the traces of its supertype, 
and in its efferent aspects (how a LOE processing a method request has effects on clients) — the 
subtype must not send more notifications than the supertype. This behavioural subtyping notion 
on finite-state machines, which is in its spirit very similar to the one of session types — "more 
offers, less requests", is defined as a simulation relation. Rossie shows that this relation ensures 
safe substitutability. 

Typestates. Based on the fact that method availability depends on an object's internal state 
(the situation identified by Nierstrasz, as mentioned above), Strom and Yemini |59| proposed 
typestates. The concept consists of identifying the possible states of an object and defining pre- 
and post-conditions that specify in which state an object should be so that a given method would 
be available, and in which state the method execution would leave the object. 

Vault [20 27 follows the typestates approach. It uses linear types to control aliasing, and uses 
the adoption and focus mechanism [57] to re-introduce aliasing in limited situations. Fugue |21||2"8"] 
extends similar ideas to an object-oriented language, and uses explicit pre- and post-conditions. 

0] also work on a typestates approach in an object-oriented language, defining a sound modular 
automated static protocol-checking setting. They define a state and method refinement relation 
achieving a behavioural subtyping relation. The work is extended with access permissions, that 
combine typestate with aliasing information about objects [5], and with concurrency, via the 
atomic block synchronization primitive used in transactional memory systems [5]. Like us, they 
allow the typestate to depend on the result of a method call. Plural is a prototype tool that 
embodies their approach, providing automated static analysis in a concurrent object-oriented lan- 
guage [6 . To evaluate their approach they annotated and verified several standard Java APIs (7j. 

|46| develop a new aliasing control mechanism, finer and more expressive than previous pro- 
posals, based on defining object views according to specific access constraints. The discipline is 
implemented in a type system combining views and a typestate approach, checking user defined 
aliasing patterns. 

Finally. Sing# [26_ is an extension of C# which has been used to implement Singularity, an 
operating system based on message-passing. It incorporates session types to specify protocols for 
communication channels, and introduces typestate-like contracts The published paper [26 does 
not discuss the relationship between channel contracts and non-uniform objects or typestates, 
and does not define a formal language. A technical point is that Sing# uses a single construct 
switch receive to combine receiving an enumeration value and doing a case-analysis, whereas our 
system allows a switch on an enumeration value to be separated from the method call that produces 
it. 

Session types and typestates are related approaches, but there are stylistic and technical differ- 
ences. With respect to the former, session types are like labelled transition systems or finite-state 
automata, capturing the behaviour of an object. When developing an application, one may start 
from session types and then implement the classes. Typestates take each transition of a session 
type and attach it to a method as pre- and post-conditions. With respect to technical differences, 
the main ones are: (a) session types unify types and typestates in a single class type as a global 
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behavioural specification; (b) our subtyping relation is structural, while the typestates refinement 
relation is nominal; (c) Plural uses a software transactional model as concurrency control mecha- 
nism (thus, shared memory), which is lighter and easier than locks, but one has to mark atomic 
blocks in the code, whereas our communication-centric model (using channels) is simpler and al- 
lows us to use the same type abstraction (session types) instead of a new programming construct; 
moreover, channel-based communication also allows us to specify the client-server communication 
protocol as the channel session type, and to implement it modularly, in several methods which may 
even be in different classes; (d) typestate approaches allow flexible aliasing control, whereas our 
approach uses only linear objects (to add better alias/access control is simple and an orthogonal 
issue). 

Static verification of protocols. Cyclone (34] and CQual [29] are systems based on the C 
programming language that allow protocols to be statically enforced by a compiler. Cyclone adds 
many benefits to C, but its support for protocols is limited to enforcing locking of resources. 
Between acquiring and releasing a lock, there are no restrictions on how a thread may use a 
resource. In contrast, our system uses types both to enforce locking of objects (via linearity) 
and to enforce the correct sequence of method calls. CQual expects users to annotate programs 
with type qualifiers; its type system, simpler and less expressive than the above, provides for type 
inference. 

Unique ownership of objects. In order to demonstrate the key idea of modularizing session 
implementations by integrating session-typed channels and non-uniform objects, we have taken the 
simplest possible approach to ownership control: strict linearity of non-uniform objects. This idea 
goes back at least to the work of [5] and has been applied many times. However, linearity causes 
problems of its own: linear objects cannot be stored in shared data structures, and this tends 
to restrict expressivity. There is a large literature on less extreme techniques for static control 
of aliasing: Hogg's Islands [35 , Almeida's balloon types pQ, Clarke et al.'s ownership types [16] . 
Fahndrich and DeLine's adoption and focus [27], Ostlund et al.'s Joe3 [52] among others. In 
future work we intend to use an off-the-shelf technique for more sophisticated alias analysis. The 
property we need is that when changing the type of an object (by calling a method on it or by 
performing a switch or a while on an enumeration constant returned from a method call) there 
must be a unique reference to it. 

Resource usage analysis. [¥T] define a general resource usage analysis problem for an extended 
A-calculus, including a type inference system, that statically checks the order of resource usage. 
Although quite expressive, their system only analyzes the sequence of method calls and does not 
consider branching on method results as we do. 

Analysis of concurrent systems using pi-calculus. Some work on static analysis of concur- 
rent systems expressed in pi-calculus is also relevant, in the sense that it addresses the question 
(among others) of whether attempted uses of a resource are consistent with its state. Kobayashi 
et al. have developed a generic framework [40i including a verification tool [35] in which to define 
type systems for analyzing various behavioural properties including sequences of resource uses 
|43| . In some of this work, types are themselves abstract processes, and therefore in some situa- 
tions resemble our session types. [TS] use CCS to describe properties of pi-calculus programs, and 
verify the validity of temporal formulae via a combination of type-checking and model-checking 
techniques, thereby going beyond static analysis. 

All of this pi-calculus-based work follows the approach of modelling systems in a relatively 
low-level language which is then analyzed. In contrast, we work directly with the high-level 
abstractions of session types and objects. 



10 Conclusion 

We have extended existing work on session types for object-oriented languages by allowing the 
implementation of a session to be divided between several methods which can be called indepen- 
dently. This supports a modular approach which is absent from previous work. Technically, it 
is achieved by integrating session types for communication channels and a static type system for 
non-uniform objects. A session-typed channel is one kind of non-uniform object, but objects whose 
fields are non-uniform are also, in general, non-uniform. Typing guarantees that the sequence of 
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messages on every channel, and the sequence of method calls on every non-uniform object, satisfy 
specifications expressed as session types. 

We have formalized the syntax, operational semantics and static type system of a core dis- 
tributed class-based object-oriented language incorporating these ideas. Soundness of the type 
system is expressed by type preservation, conformance and correct communication theorems. The 
type system includes a form of typestate and uses simple linear type theory to guarantee unique 
ownership of non-uniform objects. It allows the typestate of an object after a method call to de- 
pend on the result of the call, if this is of an enumerated type, and in this situation, the necessary 
case-analysis of the method result does not need to be done immediately after the call. 

We have illustrated our ideas with an example based on a remote file server, and described a 
prototype implementation. By incorporating further standard ideas from the related literature, it 
should be straightforward to extend the implementation to a larger and more practical language. 

In the future we intend to work on the following topics. (1) More flexible control of aliasing. 
The mechanism for controlling aliasing should be orthogonal to the theory of how operations affect 
uniquely-referenced objects. We intend to adapt existing work to relax our strictly linear control 
and obtain a more flexible language. (2) In Section 4.4 we outlined an adaptation of our structural 
type system to a nominal type system as found in languages such as Java. We would also like to 
account for Java's distinction and relationship between classes and interfaces. (3) Specifications 
involving several objects. Multi-party session types [8j [36] and conversation types [10] specify 
protocols with more than two participants. It would be interesting to adapt those theories into 
type systems for more complex patterns of object usage. 
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Appendix: Proofs of lemmas from Section 7.1 



Lemma 7.1 Suppose O h h : T. Then (a) h is complete, (b) chans(r) C dom(&) \ chans(/i) and 
(c) objs(r) C roots(/j). 

Proof. By induction on the derivation of O h h : T. The only axiom is T-Hempty for which the 
properties are true. Then T-Hide does not change either h or dom(T) so it preserves all three 
properties. The other case is T-Hadd. Let h! be the heap in the conclusion. Then children/,' (o) 
is the set of Vi which are object identifiers. Let K be the set of Vi which are channel endpoints. 
The typing derivation for the sequence of swaps in the right premise must include an occurrence 
of T-Ref for each object identifier, and of T-Chan for each channel endpoint, each followed by 
T-Swap and a number of occurrences of T-Seq. Looking at these rules, we can see that this 
implies: 

1. children;,'(o) U K C dom(T) and 
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2. dom(T') C (dom(r)\ (children? l /(o)U-ft'))U{o}. (Note that o cannot be one of the Vi because 
it is the current object in the judgement: the premise of T-Ref forbids it.) 

From (1) and induction hypothesis (c) we get children/^ (o) C roots(h). We have roots(/i) C 
dom(h) C dom(h!) and o is the only new object in h', so h' is complete. 

If we project (2) onto just channel endpoints, we get chans(r') C chans(r) \ K. From the 
definition of h' , chans(h') is equal to chans(/i) U K. Hence induction hypothesis (b) yields (b) 
again for h! . 

If we project (2) onto just object identifiers, we get objs(r') C (objs(r) \ children^* (o)) U {o}. 
From induction hypothesis (a) and the fact that o (jL dom(h) we get that o is a root in h! . 
Furthermore, all roots of h which are not children of o are also roots of h' . Thus induction 
hypothesis (c) allows us to conclude objs(r') C roots(/i'). 

Lemma 7.2 (Rearrangement of typing derivations for expressions) Suppose we have 
r*r>e:T<ir'*r'. Then there exists a typing derivation for this judgement in which: 

1. T-Sub only occurs at the very end, just before T-SwiTCH or T-SwitchLink as the last 
rule in the derivation for each of the branches, or just before T-Call as the last rule in the 
derivation for the parameter; 

2. T-SubEnv only occurs immediately before T-Sub in the first three cases and does not occur 
at all in the fourth, i.e. T-CALL. 

Proof. First note that T-Sub and T-SubEnv commute and that any consecutive sequence of 
occurrences of one of these rules can collapse into a single occurrence using transitivity. What 
remains to be shown is that these rules can be pushed down in all cases but those mentioned in 
the statement. We enumerate the cases below. 

• T-Swap. T-SUB on the premise can be replaced with T-SubEnv on the conclusion as T 
has been transferred to the environment. T-SubEnv on the premise can be replaced by a 
combination of T-Sub (for the type of r'.f) and T-SubEnv (for the rest) on the conclusion. 

• T-Call. If T-SubEnv is used on the premise to increase the type of something else than 
r'.f it can be moved to the conclusion. If the type of r'.f is changed, first note that the 
only relevant part is the signature of rrij. Suppose the subsumption step changes it from 
Uj mj(Uj) : S'a to Tj mj(Tj) : Sj. For the parameter type we have T'- <: Uj so we can use 
T-SUB on the premise to increase the type of e from Tj to Uj instead. For the session and 
result types, we have two cases: 

— if Uj <: Tj and Sj <: Sj it can just be moved to a T-SubEnv step on the conclusion. 

— if Uj = E. Tj = linkthis and (I : Sj)i^E <■ Sj, then the original conclusion of the rule 
(with T-SubEnv on the premise) was: 

r * r t> f.rrij(e) : link / < T'{r'.f ^ Sj} * r' 

and the new one with the subsumption step removed is: 

r * r t> f.rrij(e) : E < T'{r'.f ^ S'j] * r' . 

So in that case the original judgement can be obtained back from this new conclusion 
using T-VarS followed by T-SubEnv. 

• T-Seq. T-Sub on the first premise is irrelevant and T-SubEnv on the same premise 
can be removed using Lemma |3.14| Subsumption on the second premise straightforwardly 
commutes to the conclusion. 

• T-SwiTCH. Lemma [3J4| allows us to remove T-SubEnv on the first premise. Straightfor- 
wardly T-SUB can be removed as well as it just makes E' smaller. 

• T-SwitchLink. T-Sub is irrelevant; removing T-SubEnv can only make E' and the initial 
typing environments for the branches smaller and we can use Lemma |3.14| 
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• T-VarF and T-VarS. T-Stjb can increase E which becomes the indexing set of the vari- 
ant in the conclusion. By definition of subtyping for variants it is possible to increase it 
afterwards using T-SubEnv. T-SubEnv straightforwardly commutes. 

• T-Return. T-Sub straightforwardly commutes, as well as the part of T-SubEnv not 



concerning r'.f. Subsumption on T'(r'.f) can be removed using Proposition 3.15 □ 



Lemma 7.3 (Rearrangement of typing derivations for heaps) Suppose I- h : T holds. 
Let o be an arbitrary root of h. Then there exists a typing derivation for it such that: 

1. T-Sub is never used; 

2. T-SubEnv is used at most once, as the last rule leading to the right premise of the last 
occurrence of T-HADD; 

3. every occurrence of T-HlDE follows immediately the occurrence of T-HADD concerning the 
same object identifier; 

4-. the occurrence of T-HADD concerning an identifier d is always immediately preceded (on 
the left premise) by the occurrences of T-Hadd/T-Hide concerning the descendants of d ; 

5. the first root added is o. 

Proof. The first two points are a consequence of Lemma |7.2| the only expressions which appear in 
the typing derivation are sequences of swaps, not containing any switch or method call; furthermore 
their type is always Null, making T-Sub at the end irrelevant. What remains to be checked is 
then just that T-SubEnv at the end of the derivation for one sequence of swaps can be pushed 
down to the next occurrence of T-Hadd whenever there is one. This is just a matter of using 
Proposition |3. 15| in the case of T-HlDE and Lemma [3.14| in the case of T-Hadd. 

Note that these points imply in particular that in all applications of T-Hadd but the last one, 
any element in dom{T) which is not one of the m also occurs in T' with exactly the same type. 

For the third point, first notice that the premise of T-Hide implies o is a root of h because of 



Lemma 7.1 This implies that the rule immediately above T-Hide either is a T-Hadd introducing 
o or does not concern o at all (in particular, o cannot be a d,, otherwise it would not be a root in 
the conclusion). In the second case, T-HlDE can be pushed upwards. 

The fourth and fifth points are a consequence of the remark we made about the first two: if d 
is not a descendant of o nor vice-versa, then the occurrences of T-Hadd and T-HlDE concerning o 
and its descendants commute with those concerning d and its descendants as they affect completely 
disjoint parts of the environment. In the case of the last occurrence of T-Hadd there may be 
a subsumption step but it is still possible to commute with it by pushing this subsumption step 
down again. 

Lemma 7.4 (Splitting of the heap) Suppose h h : T, o : T. Let ©i = \ chans(/i J, o) and 

let 02 be restricted to chans(/i J, o). Then we have: ©i h (h j" o) : V and ©2 h {h 4- o) : o : T. 



Proof. We know from Lemma |7.1| that o is a root in h. We consider the particular derivation 
given by Lemma |7 . 3 1 where o is the first root added to the heap. Now if we look at the conclusion 
of the last rule concerning o (T-Hadd or T-Hide depending whether T is a field or session type), 
we know that at this point the heap is h J, o, and therefore the only object identifier in the 
environment is its only root: o. Furthermore, this part of the derivation is still true if we replace 
the initial with ©2, with the only difference that then the final T contains no channels, and 
thus is of the form o : T' . We also know that the type of o is not changed in the rest of the 
derivation except possibly by the subsumption step at the end; therefore T' is a subtype of T . If 
they are session types, using Proposition |3 . 1 7| we can change the last occurrence of T-HlDE to use 
T instead of X" and get ©2 h (h I o) : o : T. Otherwise, we can add a subsumption step to the 
derivation for the sequence of swaps on the right of T-Hadd to get the same result. 

For the rest of the derivation, we know that o is not used, therefore it can be removed from the 
initial environment without affecting the derivation except by the fact that it will not be in the final 
environment either. Furthermore, we know from Lemma |7. 1| that the initial environment minus 
its only object identifier o is included in \ chans(/i j o) = ©i. More precisely, the lemma gives 
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us inclusion of domains, but because subsumption is not used in the first part of the derivation 
we also know that the types are the same. Thus we can replace the first part of the derivation by 
an instance of T-Hempty using 81 and the second part is still valid (with all the descendants of 
o removed from the heap), yielding Oi h (h f o) : T at the bottom. 

Lemma 7.5 (Merging of heaps) Suppose h h : T and 0' h h! : V with dom(h)C\dom(h') = 
and dom(Q) n dom{&) = 0. Then we have + 6' h h + h! : T + V. 

Proof. Since 8 and 0' are disjoint, the channels in 9' cannot appear anywhere in the typing 
derivation for h. Thus, it is possible to add O' to every typing environment occurring in the 
derivation for h without altering its validity, yielding + 0' h h : V + 0'. Looking now at the 
derivation for h! , since the domains of the heaps are disjoint and objs(r) C roots(/i), none of the 
identifiers in T can appear anywhere in it. Thus we can add T to every typing environment and 
h to every heap occurring in the derivation for h! , replacing the T-Hempty at the top with the 
conclusion of the other derivation, which yields the result we want. 

Lemma 7.6 Suppose h h : o : S. Let (p be an injective function from dom(h) to O. Then we 
have h ip(h) : ip(o) : S. 

Proof. Straightforward. Changing the names does not affect the typing derivation in any way. 

Lemma 7.7 (Opening) If 6 h h:T, ifT(r) is a branch session type S and if h(r) is an object 
identifier o, then we know from Lemma \l A\ that h contains an entry for o. Let C be the class of 
this entry, then there exists a field typing F for C such that h h : T{r 1— > C[-F]} and F h C : S. 

Proof. We prove this by induction on the depth of r. The base case is r = o. Using Lemmas |7.4| 
and |7.5| we can restrict ourselves to the case where o is the only root of h. In that case we know 
that the last rule used in the typing derivation for h h : o : S must be T-Hide. The result we 
want is constituted precisely by the premises of that rule. 

For the inductive case, r is of the form o' .f.f. We consider the case where o' is the only root. 
The typing derivation then ends with T-Hadd and / gets populated in the sequence of swaps by 
some object identified o". Let r' = o".f, and consider what T(r') can be, knowing that in the 
conclusion r has a branch session type: the only way the type can be modified in the sequence 
of swaps is by subsumption. Indeed, T-VarS, the other possibility, introduces a variant type. 
Therefore T(r') = S' with S' <: S. We can thus use the induction hypothesis to replace T with 



F{r <-¥ C[F]} on the left premise, with F h C : S' . Then just use Proposition 3.17 to see that we 
also have F h C : S and see that the type yielded in the conclusion by this new premise is what 
we want. 

Lemma 7.8 (Closing) 7/ h h : T and T(r) = C[F] and F V- C : S, then 9h/i:r{mS}. 

Proof. Again we prove this by induction on the depth of r and the base case is r = o. In that case 
the lemma is nothing more than T-Hide. The inductive case is very similar to the above: we look 
at the type of r' (defined as above) in the T on the left premise of the last T-Hadd, noticing that 
the type of r in the conclusion can only differ from it by subsumption, this time because we know 



from Lemma 3.27 that T-VarF is never used. Hence the original type is C[F'\ with F' <: F. 



Proposition 3.15 gives us F' h C : S and thus we can use the induction hypothesis to change the 



type of r' in this premise, which propagates to the type of r in the conclusion. 

Lemma 7.9 (modification of the heap) Suppose that we have I- h : T and T * r > v' : 

T' < r' * r, and that T'(r.f) — T where T is not a variant. Let v — h(r).f . The modified heap 
h{r.f 1 — y v'} can be typed as follows: 

1. if v is an object identifier or a channel endpoint, then: 

h h{r.f ^ v'} : T'{r.f h-> T'}, v : T 



3 We know o" is an object identifier and not a channel endpoint because, according to the hypotheses, either it 
is o itself or / is nonempty, implying o" has fields. 



58 



2. if v is not an object or channel and T is not a link type, then: 



h h{r.f i ^ v'} : T'{r.f H> T'} 

3. if v — Iq and T = link /', then: 

• T'(r.f) = : Si)i^E for some E such that Iq G E and some set of branch session types 
Si. Note that this implies f =/= /'. 

. 9 h h{r.f i ^ «'} : r'{r./ h> T'}{r,f ^ S,J 

Proof. First of all, note that the hypothesis that T'(r.f) is defined implies that T'(r) is not a 
variant, hence T' is not linkthis. In other words, the judgement cannot be derived from T-VarF. 
Furthermore, the fact that T is not a variant either means that the judgement is not derived from 
an instance of T-VarS referring to field /. As this rule is the only possibility (beside subsumption) 
for a judgement typing a value to depend on, and modify, the type of a field, this implies that 
r(r./) is a subtype of T and also that the judgement would still hold with another type for /. In 
particular we have T{r.f h-> Null} * r > v' : T' < T'{r.f h-> Null} * r (a). We will in the following 
use this judgement (a) rather than the one in the hypothesis. 

We prove the lemma by induction on the depth of r, but the inductive case is straightforward 
(just apply the induction hypothesis to the left premise of T-Hadd). In the base case, r is an 
object identifier o. We use Lemma |7.4| to consider a typing derivation for the sub-heap h 1 o. Let 
r o = o : T a and O be the environments corresponding to that part of the heap. We look at the 
application of T-Hadd which ends the derivation for O h h a : T . As T is not a variant, it is 
possible to consider that / is the last field to get populated in the swap sequence. We thus have 
something of the form: 

(1) — 

,„ „ , r 2 * o > v : T v < r 3 * o 

(T-Swap) 



?2 * o > f <r> V : Null <a r 3 {o./ n> T v } * o 

(T-Seq) 

ri * o >...;/« v : Null < r 3 {o./ i-» T v } * o 

(T-SubEnv) 



8 h (h\ o) \ o : Ti v ' r x * o >...;/ o v : Null < r o * o 

(T-Hadd) 

G h h I o : r o V ' 

with T v <: T and T 3 {o.f h- > T„} <: r o . If we change the type of o.f, this last relation becomes 
r 3 <:T {o.f^ Null} (b). 

What we want to do is to replace the judgement on the top right, which is an application of 
some rule (1), by ajudgement typing v'. For this, we need the rest of the environment. We consider 
the judgement for the rest of the heap, O \ O h h t o : T \ o. Since the domains are disjoint, we 



can apply Lemma 7.5 to this and the leftmost premise of T-Hadd, yielding I- h \ o : F \ o + IV 
If we replace our left premise with this, the initial environment we get on the top right is now 
r4 = r \ o + T2, as the additional part is unaffected by the sequence of swaps. This environment 
is almost T{o.f n- Null}, but not quite. We now have three cases depending on what rule (1) is, 
which correspond to the three cases of the lemma. 

1. If (1) is T-Ref or T-Chan, meaning v is an object identifier or a channel endpoint, then 
T 2 = T 3 ,v : T v . Using (b), this yields T 2 <: T Q {o.f h-> Null},u : T v . Adding T \ o to both 
sides, we get T4 <: T{o.f ^ Null},u : T v . If we replace the initial environment in (a) with 
this one, we get the v : T v back in the final environment. We then use Lemma |3.14| to 
replace this initial environment with T^, and T-SubEnv to change T v into T in the final 
one: * o \> v' : T' <l V {o.f i-> Null}, v : T * o. Just see that it yields what we want at the 
bottom of the derivation. 

2. If (1) is T-Label or T-Null or T-Name, i.e. if v is a literal value of non-link, non-linear 
type, then T 2 is identical to T3 and we have, using (b) and adding T \ o to both sides, 



T4 <: r{o./ H> Null}, so we can directly (with Lemma 3.14) use judgement (a) 



If (1) is T-VarS, the last possibility, then v is a label Iq and T v is link /' for some /'. As 
it has no strict supertype, we have T = link /' as well. We also have T^o.f) = (Iq : S) . 
From (b) we have that T (o.f ) = T(o.f') is a supertype of this variant type, thus also a 
variant. This implies that (a) cannot come from a T-VarS concerning /'; therefore, T'(o.f) 
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is a supertype of T(o.f') and hence, by transitivity, of (lo ■ S) , which gives us the first item 
of the conclusion, with S <: Si . We now just have to notice that T 2 = T 3 {o.f S} and 
that (a) is independent of the type of /' just like it is of the type of /, and we can conclude 
similarly to the two previous cases. □ 

Lemma 7.10 (Substitution) // this : C[F],x : T' * this > e : T < this : C[F'\ * this, and if 

r(r) = C[F], then: 

1. if T' is a base type (i.e. neither an object type nor a link) and v is a literal value of that 
type, or if v is an access point name declared with type (£) and [(E)] <: T' , we have: 

T*r> e{7J : T <J T{r ^ C[F']} * r. 

2. ifT' is an object type and v is an object identifier or a channel endpoint, we have: 

r, v : T' * r > e{ v / x } : T < T{r M> C[F'}} * r. 

Proof. In order to do an induction, we add the following case where x is still present in the 
final environment : if we have this : C[F],x : T * this > e : T < this : C[F'],x : T" * this, and 
if T' is an object type and v is an object identifier, then we have F,v : T' *r > e{ v / x } : T < 
T{r^C[F']},v:T"*r. 

We prove this by induction on the derivation of this : C[F] , x : T' * this > e : T <\ this : C[F'] , V * this 
(where V is either empty or v : T" depending on the case). For most toplevel rules, the result is 
immediate. The only ones for which it is not are T-Var and T-LinVar. For T-Var the result 
is obtained using either T-Null if T" is Null or T-Label and T-Sub if it is an enumerated type. 
In the case of an extension adding new base types, we assume there is a similar rule to type the 
corresponding literal values. For T-LinVar, if v is an access point name the result is obtained 
using T-Name and T-Sub. Otherwise, v is an object identifier and the result is obtained using 
T-Ref, noticing that because T(r) is defined and v is not in V, the path r does not start with v 
and the premise is satisfied. 

Lemma 7.11 (Typability of Subterms) If V is a derivation ofT*r\>£(e) : T < T' * r' then 
there exist T 1; r\ and U such that V has a subderivation V concluding T * r \> e : U < Ti * r 1 
and the position ofV in V corresponds to the position of the hole in £. 

Proof. A straightforward induction on the structure of £; the expression e is always at the extreme 
left of the typing derivation for £{e). 

Lemma 7.12 (Replacement) // 

1. V is a derivation ofY*r\>£{e) :T<\T'*r' 

2. T>' is a subderivation of T> concluding T * r \> e : U oTi^ri 

3. the position of V in V corresponds to the position of the hole in £ 

4. T" * r" t> e' : U < Ti * n 
then T" * r" > £{e>) :T<T'*r'. 

Proof. Replace V in D by the derivation of T" * r" D> e' : U < T\ * r\. 
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